DEV Community: Erik Dietrich

Want the Answer Engines to Send You Traffic? Show Up in Organic

Erik Dietrich — Tue, 17 Mar 2026 20:50:16 +0000

Editorial note: I originally wrote this over on the Hit Subscribe blog.

When it comes to answering the question, "what causes a site to earn more answer engine traffic," I have two disparate things going for me that create a unique opportunity:

A bit of academic training in, and a long professional history of, data-driven analysis of complex systems.
Access to a LOT of instances of Google analytics and marketing systems of records with normalized views across them.

Add to that the fact that I just recently built out some Osiris functionality to create aggregate queries across all data sets and I realized, "hey, it wouldn't be too hard to take a decent statistical look at this." Not that I don't find endless speculating and arguing on LinkedIn to be fascinating. I just don't trust my instincts nearly enough to guess at stuff.

Let me get the spoiler out of the way quickly and then dive into specifics.

Far and away the best predictor of a site earning a lot of traffic from answer engines was whether that site was earning a lot of traffic from search engines.

Now because I realize this just sounds like copium from someone comfortable with SEO as a channel, I want to elaborate on methodology and specifics. And I also want to dive into a few subtleties and conclusions that aren't immediately obvious. Because the actual takeaway here isn't just "do traditional SEO and answer engine traffic will take care of itself."

Methodology (In Plain English, I Promise) and Caveats

One thing that I want to mention prominently is that everything about this is anonymized. We NDA with everyone that gives us systems of record and we take that obligation seriously.

With that out of the way, let's start off talking about my "stack" for this. We use BigQuery and a proprietary modeling system for our Osiris offering and use @airbyte-quinton to ingest client data into that from GA4 and other marketing systems. For the purposes of this experiment, I ignored other analytics traffic sources for both consistency and to ensure that I was comparing apples to apples.

I limited the study to a subset of GA4 instances to which we have access, totaling exactly 30. These instances ran the gamut of traffic from almost nothing to 7 figures per month. That was intentional.

From there, I used VSCode, Python, Pandas, and ChatGPT to vibe code up a regression analysis. I have a lot of software engineering in my background, but have never used Pandas, and this let me run the experiments in hours rather than scaffolding something up over a week.

With all of this in place, I wrote a series of SQL queries against BigQuery to extract apples-to-apples values across the GA4 instances for the experiment. For instance, this allowed me to build lists of things like "total channel traffic volume in 2025" and "number of distinct URLs" across all the client BigQuery schemas.

With all of this in place, I ran regression analysis. I won't get into the weeds of that unless any of you reading specifically request, at which point I could sanitize the code and write a follow-up post.

A False Start: Answer Engine Share

I approached this in iterative fashion, starting simple. The first dependent variable I decided to look at was "answer engine share," or "percentage of site traffic that comes from answer engines." (You can see this here in our public Osiris demo, and average AE share between 2-4% is typical).

Basically I reasoned that larger sites would have larger traffic of all kinds (a hypothesis that I would of course later validate and am writing this post about). So I figured I'd control for that by seeing if any other variables predicted a higher percentage of answer engine traffic. Meaning, if pound for pound, some sites were earning WAY more than others, I wanted to examine the predictive variables about those sites.

Well, all for naught. Absolutely nothing I tested showed even a slight correlation for predicting a higher answer engine share, including:

Organic traffic volume
Number of URLs
Keyword coverage % (basically what percent of a site's URLs targeted organic intentionally)
Domain authority (Moz)
Rank performance (we have a model that projects an expected rank for a domain/keyword pair and I measured a site's tendency to underperform/overperform the prediction as a proxy for "good at SEO")
Number of "commercial" URLs (proxied this with the percentage of URLs containing obviously commercial tokens, like "best" and "comparison" and such)

This isn't to say that none of those things matter in any way at all. But it is to say that none of them was even remotely predictive of a higher answer engine share. Good at SEO, bad at SEO, large, small, authoritative, not, it didn't matter at all.

So I switched gears and thought, let's not overthink this. The goal here isn't answer engine share (which you could trivially throttle up by disabling other site channels). You just want the bots to send you traffic. So let's see if we have anything that predicts traffic.

Asking a Better Question: What Predicts More Answer Engine Traffic?

At this point, I switched the dependent variable in question to answer engine traffic. Well, more precisely, I switched it to the natural log of answer engine traffic, because all the cool kids like Moz create metrics that way. Or maybe because it stabilizes variance and allows for the fact that going from 1 visitor to 1,000 is a much bigger deal than going from 500,000 to 501,000. Either way.

I then picked organic traffic (log of organic traffic) as the first independent variable to try.

When I reran the model with organic traffic as the predictor it was like a slot machine just paid out. Organic traffic explained approximately 93% of the variance in answer engine traffic. The biggest determinant of answer engine traffic is whether you already have meaningful organic search traction.

Secondarily, total site traffic was also strongly predictive (around 90%), but not quite as predictive as organic traffic. Domain authority was somewhat predictive, but with a much lower score, and the rest of the variables that I'd tried in the last round had no correlation. And various flavors of traffic and domain authority also correlate heavily with one another.

What about the Other 7%?

This is where a little intrigue enters the mix on an ongoing basis. I would have thought that some of the other concerns would contribute, especially given that AE traffic tends to land more on commercial pages. But nothing so far.

So we're in a state that's kind of like when someone discovered Neptune and the solar system was mostly settled, but there are still some possible dwarf planets and planet X-es or whatever. There's a compelling explanation for most of it, but some interesting mysteries still out there at the margins.

With this analysis, there are positive and negative outliers in the AE/Organic relationship, and those outliers have SOMETHING in common. It just remains to be seen what variable(s) those are, and those variables will become the evolution of the SEO playbook into a GEO playbook.

Practical Takeaways

So as you can see, this is neither a "just do SEO and you'll be fine" post, nor is it the magic beans you tend to see masquerading as "GEO strategy." And it's also not complete, because I intend to do more work here when I have a chance (more on that in a second). So here's how I'd frame what you can take away.

If you want answer engine traffic, your best bet is to grow your site and your brand, particularly organic (which makes sense, since both search and answer engines follow a Q&A paradigm).
It's an interesting figure, but there is no point in making "answer engine share" a first-class goal. In fact, that's probably counterproductive.
Whatever you're adding to your GEO playbook, you can probably skip generating a lot of URLs or focusing exclusively on commercial terms, except inasmuch as that fits into your traditional organic strategy.
You're not going to on-page GEO hack your way to a large presence in answer engines without doing the traditional build work of the SEO channel.

What We'll Do Next

As I alluded to earlier, I'm still interested in chasing the remaining 7%. And I have some things that I'd like to test, though some of this data is far easier to gather than others and not all of it has equal precision and fidelity. Caveats aside, I'm thinking:

Content form mix (definitions, tutorials, comparisons, etc)
Prevalence of on-page GEO tactics
Branded search volume
Content freshness/age
Crawler hygiene
Historical site performance (seems unlikely to matter, but you never know)

If you have any thoughts on these candidate variables or input on what I might be forgetting, I'd love to hear it. Hopefully we can start to tease out some meaningful, non-anecdotal data about what sorts of tactics actually work as the landscape changes.

The Interesting Case of Flattening Mean Time to Mediocrity

Erik Dietrich — Wed, 18 Feb 2026 16:19:26 +0000

Editorial note: I originally published this over at the DaedTech blog.

I have a complex relationship with generative AI.

On the one hand, I use it constantly and find it to be a godsend for some formerly laborious stuff. I’ll never visit another recipe site, comb through some dusty gadget troubleshooting site, or write boilerplate code by hand as long as I live. Read through terms and conditions? Pfft. “Read this and tell me if I should care.”

On the other hand, I can’t tell you how boring I find the endless river of LinkedIn thought leadership about AI. I’m also not especially fond of prognositcation along the lines of “what if the thing that I confuse with a human, and hear me out, did the kinds of things that humans do!?”

Compelling take there, Nostradamus.

This is all to say that my take on it is that generative AI is genuinely useful. But in my estimation, it’s only genuinely useful for a small fraction of what the breathless, incessant hypsters claim it is useful for. I think this take is similar to Cal Newport’s in this video examing whether the tech is a “disappointment.”

Today, I’d like to zoom in on what it’s actually useful for.

Mean Time to Python Mediocrity

Cal Newport likes it for programming, and I was just reading Jonathan Stark’s daily email, and he seems to agree. And both of these square with my experience, where just tonight I was having ChatGPT vibe code me up a Python script to aid in a regression analysis of 40ish Google Analytics instances to see if I can find significant correlation between properties of websites and share of traffic referred by answer engines.

Since I have ChatGPT generate throwaway scripts a fair bit, I can safely predict the workflow will be something like this.

I tell it to generate something, but I’m too vague.
I refine.
It generates something.
I get angry and swear at it for a few rounds before I calm down and realize I’m swearing at a probablistic function.
Regrouping, I give better direction.
Iterate/repeat until joy (or maybe 10% of the time I realize it’s just not up to the task).
Marvel at how quickly I was able to get something up and running.
Marvel at how it generates tech debt even in small applications, like a human entry level programmer.
Stop marveling and move on because I’m trying to get things done.

I don’t write a lot of code these days, and I never really wrote much in Python. So it’s generally a pretty killer use case that I can get something legitimately useful up and running less than a half hour. And since it’s throwaway code, it really doesn’t matter the code is mediocre.

Time from 0 to medicority is less than 30 minutes.

Mean Time to Web Design Mediocrity

This metric isn’t limited to Python, either. A few years back, I had Hit Subscribe’s head of sales at the time hire a small web dev shop to give the Hit Subscribe site a makeover. They used some WordPress theme abomination called Divi that I, thankfully, have had minimal occasion to touch. I’m not positive, but I think this is an original architecture design document for the WYSIWYG editor of it.

Fast forward to last fall, and I wanted to play with some site concepts. I wanted no part of the Jenga experience of using their design GUI, so I hatched a plan. You see, this is what the webpage looks like if you force it to render in the classic WordPress editor. A soup of shortcodes.

I figured there were probably enough desperate souls on the internet with questions about this that ChatGPT would have decent knowledge of it in its training data. So I described what I want and literally prompted it with “vibe code me up a DIVI page and give it to me in shortcodes I can paste in.” And it worked surprisingly well.

Within half an hour I had something that looked alright-ish. It was another situation where the time to mediocrity was amazingly low, thanks to Gen AI. (As a coda, Lyndsey who does growth for Hit Subscribe and is talented with design eventually took over and created the actual, live Osiris page. I’m not sure how much, if any, vibe-anything she used).

But we’ve got a theme here. I’m not good at UX stuff. I’m not good at Python scripting. But with an LLM I can get to mediocre in minutes, rather than days.

Mean Time to Total Mediocrity

I realize that this is true across the board. I’ve recently used ChatGPT to help fix up an old Sega Genesis, troubleshoot a firepit, and navigate various state labor law bureaucracies. My skill level at all of those things is 0, but with the help of the LLM, I can LARP as mediocre. And heck, with a bit of practice, maybe even ascend to mediocre in earnest.

It makes sense. LLMs train on the wisdom of the internet, such as it is. They then use this wisdom to predict what word the user wants to see next. They are, essentially, an oracle that produces mediocre skill and knowledge instantly, on demand.

LLMs have thus utterly flattened society’s mean time to mediocrity.

But what does this mean, exactly? What does it mean if anyone can immediately be mediocre at anything they want?

What does it mean if a content marketer with no programming aptitude can suddenly simulate being a mediocre programmer? How about if a sales rep forwarding a contract can suddenly decide to be a mediocre paralegal? How about an exec becoming a mediocre version of anyone in the org chart below them to help with micromanagement? It’s all on the table.

At first blush, this seems like it would be largely and unambiguously positive. We can all become “T-shaped” or “specializing generalists” or whatever management buzzword for this is poppin’ these days. If you’re a really good widgeteer, you can still be that, while also bringing universal mediocrity in all other fields to bear, which is certainly a little better than a mix of ineptitude and novicehood that you formerly had.

Considering Possible Downsides

Or is it?

According to a recent study, this capability is starting to produce burnout.

Specifically, because “productivity” and the “variety of tasks they could tackle” increased, people took on more work. So they take on these new responsibilities, at which they’re immediately (and unearned) skill level mediocre. And then.. yeah, huh. Now you’re doing your original job, plus a bunch of other ones that you’re not actually very good at and maybe aren’t quite as awesome as you originally thought when you Mary-Sued your way to mediocrity.

But if we zoom out even more and look at the bigger picture in a corporate workforce, what’s the end game here? Are we going to perform an about-face from millenia of moving towards increased specialization of labor? Is every content marketer going to be a programmer, every salesman a lawyer, and every executive an individual contributor? Should everyone become mediocre at everything?

The Unclear (and Interesting) Future of Labor Specialization

This is genuinely a pretty open-ended question and musing on my part. I don’t intend this as a rhetorical condemnation, and I’m not writing some kind of Swiftian modest proposal. I’m earnestly curious because this capability seems both locally powerful and macroscopically limiting, so I don’t know where it goes.

And, while it’s cool for me to be able to fix Sega Genesis in my spare time with my son, I’m not really sure that medicore web design is the best of use my time in my role for Hit Subscribe. 5 years ago, I wouldn’t have attempted it. But in 2025, I had ChatGPT in an open browser tab, practically egging me on to indulge this side quest, notwisthanding the fact that any competent management consultant would have slapped my hand before I started prompting.

For better or for worse, I’d argue that the main contribution of GenAI / LLMs to date is smashing our collective mean time to mediocrity from days, weeks, or months, to mere minutes. What we as humanity do with our newfound and boundless mediocrity is the open question.

Technology Done to You, Not for You

Erik Dietrich — Fri, 30 Jan 2026 07:07:52 +0000

Editorial note: I originally published this over at the DaedTech blog.

About 6 months ago, I teased a series on the idea of facadeware, largely starring our lemon of a Grand Cherokee, but speaking more broadly to a problem with how we’re developing technology. Specifically, I defined this concept as:

Facadeware : superficially advanced gadgetry with an actual net-negative value proposition.

I’d like to start unpacking that and write my series. Now, I’m not going to do what so many bloggers do and promise to write regularly again, since I have no idea if I’ll be able to back that up. But I am now through my two relocations in two months, settling into a permanent location, and hoping to have at least a thin sliver of free time to once again indulge my deepest passion: ranting discursively on the internet.

(I won’t belabor the point here, but for anyone interested, I’ll add a personal update as a footer to this post.)

Before I tell the tale of my Jeep in subsequent posts — and tell it, I will, rest assured — I want to expand on the concept of facadeware. I also want to reemphasize that I would no longer feel good about applying the label “technologist” to myself, descriptively or aspirationally. And that’s not because I now mostly do bureaucratic business ownership stuff for a living.

It’s because I no longer think “technologism” is worth aspiring to, given the state of technological advancement.

Handing in My Technologist Card

Before going any further, I’d like to reiterate that I still like to program, build, tinker, and improve. Hell, just tonight I performed some quixotic field surgery on a Keurig, successfully bringing it back from the dead briefly, before it re-died in a blaze of cooking circuitry. It isn’t a question of my tastes or interests changing, but rather that I increasingly don’t think that the way we, humans, are advancing technologically is a net positive.

In fact, I’d go so far as to claim that I think we have collectively, technologically regressed over the last 10-15 years, notwithstanding a never-ending slew of phones that are slightly bigger, or thinner, or… something… each time. Technology in this time has advanced, in a sense, for some definitions of “advanced.” More computations are happening, and the cost of that computing is going down. Various things are getting faster, more parallel, and certainly they’re spewing shit at us in higher volumes than ever before. Endless scroll wasn’t around 15 years ago, and we now have that. So, that’s, uh, awesome, I guess.

Things are progressing down a path. There are undeniably more gerbils running in more, bigger, gerbil balls, flinging more gerbil poop into the universe than ever before. Nobody can look at our world and be anything but impressed at the advancements in gerbil poop per cubic meter per hour.

But does gerbil poop, impressive in its volume and efficiency, make anyone’s life better?

A Meaningful Definition of Advancement

At this point I’m going to back slowly away from the gerbil metaphor and trust that you’ve absorbed my implicit point that more-faster-cheaper isn’t a synonym for better. But if more cores and circles on the back of my phone aren’t necessarily better, what is necessarily better?

What indeed is the purpose of technological advancement?

Well, I’d argue that the purpose has historically been to improve the lives of users of the technology. For most of my life, and the 20th century preceding my life, I think one could argue that this was generally the primary goal of most technology (allowing for the exception that a lot of advancement comes from weapons research and is later repurposed for benevolent applications). Technologists built stuff to make their and others’ lives better. The user was the hero, and the technology was the enabler of the hero’s journey.

To drive this home consider the fictional Star Trek universe. I’ve recently learned a term “solarpunk,” that, if I’m understanding it correclty, could describe that universe. In that world, the crew of the Enterprise says things like “computer, make me an 8 course Thanksgiving meal” and it just happens without a lot of navel-gazing and mythologizing about how the computer does it and how it’s disrupting the farming industry.

The fabricator, the warp drive, the holodeck — these things all just serve the occupants of a galaxy with a substantially better standard of living than we enjoy. Centuries of technologists focused on improving the lives of others led to meaningful, life-changing outcomes. This is what I signed up to participate in when, 30 years ago, I started to consider myself an aspiring technologist.

And this is categorically not what we’re doing any longer. So I’m out.

Where We’re Heading Instead

When I first arrived at our new home in Phoenix, the plumbing wasn’t yet hooked up to our fridge, so I was temporarily forced to make ice cubes in trays, like some kind of savage of a bygone millennium. I went to Walmart and bought a couple of ice cube trays and found myself pleasantly surprised by an advancement in this technology, even though I paid like 40 cents for them or something. They had a lid that fit over the top with a coverable hole in it, so that you could easily fill them and walk to the fridge without sloshing water all over yourself.

I thought to myself, “this is a legitimate, genuine improvement that makes my life better in a meaningful, if tiny, way.”

I then realized that was more than I could say for most of my SaaS subscriptions and gadgets.

Google has recently pioneered new ways to punish me for using uBlock Origin. Our Jeep has recently showcased a major breakthrough in showing ads on our nav system. Netflix and other streaming services have explored sophisticated ways to annoyingly turn off my TV if they think their engagement stats are dropping, and they’ve happily shared that knowledge with traditional telecom companies. And everything, and I mean everything, has some kind of moronic AI chatbot that nobody wants, and serves only to explode the failure density of every applied technology in our lives.

Technology is no longer done for us. It’s done to us.

We are no longer the beneficiaries. We’re the marks. Improving people’s lives via technology has taken a backseat to extracting money, time, and attention from them via the same.

And, again, with that, I’m out.

The Perverting of Incentives

So what changed, exactly? Well, I promise you that I’m not going to treat you to some oversimplified “{Tech Company} is evil” take on this. I’d like to look at it more structurally because I think a combination of factors have body checked us off course from a Star Trek future to one that looks more like Ready Player One, with notes of the Matrix.

1. A Preoccupation with Efficiency

Let’s start with something easy. If we anchor the true measure of technological advancement to the question, “does it improve someone’s life,” B2B technology immediately occupies a weird gray area.

To understand what I mean, imagine that I invented a magic orb that allowed you to complete all of your work twice as fast as you currently do. Does that improve your life?

Well, it depends. Do you go from a 40-hour week to a 20-hour one and use the rest of your time for Tai Chi or Cricket or whatever people do? Or do you just immediately start producing what used to be 80 hours of output in your designated 40-hour work time?

The difference matters a lot. If you do the first thing, your life is way better. If you do the second thing, the shareholders of your employer’s lives are way better.

I would argue that thing two is a lot more likely, should I hand you this magic orb. As such, one could argue that B2B technologies rarely improve people’s lives, except indirectly the lives of stockholders. And, while I wouldn’t argue that this is exactly a bad thing, it does mean that B2B technology advancements are generally pretty orthogonal to increase in quality of life.

And yet, B2B advancement occupies an absolutely massive slice of the total amount of tech work and R&D that we see. Our collective preoccupation with improving efficiency is a pretty serious distraction, even before you get into the weeds of how much posturing and bullshitting tends to emerge naturally from B2B transactions around technology (a topic for another time).

2. Performative “Geeking Out”

Another development related to posturing and bullshitting is performative enthusiasm around emergent technologies. As a quick shorthand for my point here, consider how when things like crypto and gen AI hit the scene, all sorts of people were suddenly super, even weirdly, into them. And very, very happy to say so again and again and again on LinkedIn.

I trace the roots of this back to the explosion of software engineering as a viable career path and bootcamp culture. At some point, genuine enthusiasm gives way to performative enthusiasm. You talk about eating, breathing and sleeping some stupid Javascript library less because it genuinely blows your hair back and more because it’s culturally appropriate, or you think some line manager wants to hear it.

The way this feeds into value-free software and facadeware is via main character syndrome. If you’re entirely focused on navel-gazing about what you’re using and how you’re using it, you tend to lose the plot on building something that anyone wants or needs. “Is anyone going to use this? Who cares? It’s microservices in the cloud for AI. That’s the real headline.”

3. The Explosion of Subsidized Cheapness

I grew up without cable television until I was maybe 14 or 15. And this was before it was sort of hipster cool to go around telling everyone how you don’t have a TV or cable. We were just behind the curve, I guess.

And because of this, I grew up in a world where television offered a relatively (by today’s standards) benign Faustian bargain. We didn’t value television enough to pay for it. And, we didn’t have to… provided we were willing to sit through some commercials for sponsors generous enough to subsidize my viewing of the Teenage Mutant Ninja Turtles cartoon. It was a great time to Cowabunga, indeed.

Of course, sponsored programming long predated my 80s cartoon watching, but this was a relatively limited concept, historically. This is no longer true. The world has absolutely exploded with crap that we kinda sorta want but aren’t really willing to pay much, if anything, for. And the world has similarly exploded with increasingly subtle, complex, and insidious Faustian bargains.

At no point in its existence has Facebook managed to not suck enough that people would pay in any kind of quantity for membership. So what does Facebook do? Improve the product to the point where users value it enough to pay for it? Scrimshaw! Preposterous!

Nah, they engage in a carefully choreographed long game of precision enshittification, letting you doom scroll through boomer rage bait to your heart’s content. At least, to your heart’s content as long as you’re willing to sit through weird ads and have your usage and personal data mined and sold off to the highest bidder.

The last 20 years has been a kind of Cambrian explosion of low value crap in our lives that sticks around only because the actual cost to us is hidden, opaque, deferred, and complex. This is what I mean by subsidized cheapness.

4. Initially Unprofitable Monopolies and Funded Long Games

And, hey, speaking of Facebook (or, Meta, I guess, at least until Zuck decides to rename them “AI” or “Crypto” or something that will be the absolute death of whatever he names it), let’s talk about another trend heavily interwoven with enshittification. I’m talking about a dark pattern that has emerged in the world of venture capital.

I’ll lead with a (slightly oversimplified) example: Uber. In a nutshell, the business strategy is this:

Disrupt an existing paradigm (which, to be fair, could use a bit of disruption) with something interesting and novel enough to attract a lot of users.
Price it in an unsustainable way to encourage exponential growth.
Use that hockey stick user curve to secure an endless river of venture capital.
Use that venture capital to continue operating massively unprofitably until you habituate your users and drive the existing paradigm and any would-be competitor out of business.
Look around, see that you have a monopoly and an addicted user base, and get busy with your enshittification to start paying back investors.
Use funds and position to create an unassailable moat around your monopoly (or cartel, depending on the specific brand).

Now I don’t really want to get into any political stances here, and please don’t interpret this as me taking an implicit stance calling for more regulation (my feelings on this are both complicated and not overly relevant at the moment). What I want to zoom in on here is the relatively small window of time here during which anyone is actually trying to make users’ lives better. Or, at least, that might coincidentally happen during the course of pursuing the first-class goal.

If you’re executing this playbook, your first-class goal is to demonstrate an ability to attract new, active users along an initially exponential curve. One tactic to achieve that would be with an actual value proposition for them. I’d argue that Uber had this — summoning rides with better transparency and cash not changing hands was a legitimate improvement to quality of life. But this isn’t necessarily required. You could also get a bunch of daily active users with network effects, trickery, rage bait, or any other number of things that exploit human cognitive bias.

And after the initial period of attracting users, there’s pretty much zero incentive to improve their lives in any way. You do need to retain them, but remember that they’re habituated and you’ve created a monopoly, so the demand is relatively inelastic. This asymmetric situation means that you’re now probably better off deploying technology to exploit them than to win them over. What’s the point of the latter? You’ve already won.

5. Recurring Revenue and the Rental of Everything

Exploitation isn’t limited to well-funded startups by any stretch of the imagination, either. “Recurring revenue all the things!” is hardly unique to Silicon Valley or venture backed startups in general. They’re simply equipped to play longer games than others, but you can find pointlessly recurring revenue in everything from hot dog loans at Costco to bootstrapped info-product hustlers moving from selling courses to community memberships.

As a business owner that sells high ticket items into the enterprise, I can wistfully (and jealously) appreciate the stability of recurring revenue compared to the big game hunting of enterprise deals. So much so, in fact, that we’ve developed a subscription product-service hybrid offering. I’m not above the allure of recurring revenue, and in general, I’m probably not completely free of being part of society’s facadeware problem. But I digress.

In a world where we’re all told how much better an ‘investment’ owning a home is than renting one, we’re ironically all moving toward renting absolutely everything else in life, all the time. Remember when you bought music or movies and owned those? Not anymore, thanks to streaming! Remember when you’d go to the store and buy Microsoft Office? Not anymore, thanks to SaaS! Remember when you owned the infrastructure and servers on which your applications ran? Not anymore, thanks to the cloud!

We increasingly rent everything and own nothing because, as any landlord will tell you, collecting rent is just good business. (As with property, there are certainly valid use cases for subscriptions/rent — I wouldn’t in good conscience have subscription offerings if I didn’t think they provided value).

The problem with every business trying to optimize for leasing things to everyone is that it creates incentives for facadeware.

If there’s a durable component to the offering, it’s in the provider’s interest to make things that need replacement more frequently. If utilization has material cost, your best customer is one that doesn’t actually use or remember they’re paying for the offering, like a gym membership. And so on and so forth. Thus what winds up occurring is the deployment of technology in zero sum situations that treat customers as adversaries: UX that makes it harder to find the “cancel” function, for instance.

6. Decoupling User from Customer

The US has just the worst imaginable healthcare system — a snarled mass of bureaucracy involving insurance companies, government, regulation, and, for some reason, your boss. Franz Kafka would blush if he got a load of a routine physical for someone in the US.

And one of the many reasons for this is the complete severance in the market of supply and demand. Walk into a hospital and ask for an Advil, and ask what it costs. “$13,274 for one Advil!? I’m going to ask my insurance company about this!” “Oh, I didn’t realize you had Bureaucratic Cross Bureaucratic Shield, you should have said so! It’s only $450 for that Advil in that case. Oh, wait, nevermind, Mercury is in retrograde, so tell you what, we’ll just give it to you for free.”

In between consumer and producer of goods and services in US healthcare, there exists an opaque and capricious bureaucracy in the form of insurance companies and micromanaging legislators. In that climate, meaningful value signals between the transacting parties cease to exist.

Technology seems to be following the collapsing US healthcare system down this same path, where the user of a technology and the customer are increasingly rarely the same person. The aforementioned Facebook comes to mind. You, dear reader, are not Facebook’s customer — you are the product. But this is also true in more benign senses in, say, the B2B world. A VP of software decides to buy some tool after the tool vendor’s sales team treats him to a golf retreat, and suddenly all of the department’s engineers are users, but not buyers, of salesman’s technology.

Do a quick inventory of the tech that you use in your life, versus the tech that you explicitly pay for. Do you personally send checks to Google or Apple for your phone’s OS? How much of your work software do you pay for? Youtube, TikTok, Facebook, et. al. Writing any checks for those? Sending any bitcoins anywhere or venmo-ing them? If you are paying any of these vendors, it’s likely a token fee compared to the price you’re paying in ads, attention, and enshittification tolls.

When the user of an offering and the buyer are not the same person, incentives get weird and perverse. Fast. And when you think of it this way, is it any wonder that the technology is usually done to you, rather than for you?

For the most part, you’re digital cattle. The technology in your life exists to keep you lean, tender, calm enough not to damage your valuable meat, and just far enough north of miserable not to make an adrenaline-fueled dash for the exit.

Can We Get Out of This Mess?

Having gone through a lengthy exercise in defining and lamenting about the problem, I want to move on to a note of hope, and talk about what I think is a viable alternative. Because I do have a framework in mind that can at least alleviate the crushing feeling that everything technical sucks these days. And maybe we could even start nudging gradually back toward a more solar punk future.

I’ve given this a lot of thought.

At first I thought the path to joy could lay in re-simplifying transactions. Let’s shoot for a world free of Facebooks and rentals and get back to a paradigm of buying and selling via direct value exchanges. But this would require a lot of onerous regulation and buy-in, and it’s not exactly catchy. “Hey, let’s go back to, uh, doing commerce, but, you know, the simple kind,” to which all reading would likely respond, “okay, grandpa, let’s get you home.”

But the more I thought about it, the more I realized that, while simple and direct incentives would certainly help, their absence isn’t the root cause of the facadware epidemic in which we find ourselves. I think complex transactions and technology that actually improves people’s lives could coexist.

Solveware as an Antidote to Facadeware

Instead, the solution came to me as I failed to fix my Keurig.

I had my last Keurig for 7 years or something and used it heavily. This was a reliable machine, and I have every reason to buy a new one. Except, I don’t want to. I won’t.

And that’s because every experience I’ve had in the last few years is that new things absolutely suck. I’ll get into this in a lot of detail when I talk about my Jeep and some detail with an upcoming facadeware taxonomy. But they’re genuinely cripplingly flaky, due to a combination of no incentive to make them last, and utterly unsustainable complexity with a million points of failure. I don’t want a new Keurig, because I suspect it’s going to be an ownership nightmare and, more critically, an endless problem.

And conceiving of this endless problem was the aha moment.

I don’t want a fancy coffee maker with bluetooth. I don’t want one that tweets. And please, for the love of all that’s holy, don’t force one with “AI” on me.

I want a coffee maker that reliably makes me a cup of decent coffee in a few minutes, day in and day out. I want it to fade into the background and make “morning coffee” a permanently solved problem. In fact, I don’t care if it’s a coffee maker at all, as long as “decent, warm, morning caffeine” is, again, a permanently solved problem.

I want solveware.

Good technology, I realized — technology that meaningfully improves people’s lives — is technology that durably or permanently solves my problems. Perhaps the platonic ideal of this is a measles vaccine. As a child, in an event I’ve long forgotten, someone stuck a needle in me and made measles a permanently solved problem in my life. My little ice cube tray thingy made spilling on myself while walking from sink to freezer a permanently solved problem.

And thinking about the fictional Star Trek universe, how would you really think of things like the holodeck and the fabricator? Nobody on the show was performing excessive maintenance on these techs, or “geeking out” about how they were made. In that universe, they are solveware. They fade into the background, permanently solving meaningful problems, like hunger, time spent cooking, and gaming/recreation.

Redefining Expectations

I can’t draw a map to how we can stop being victimized by and buried in facadeware. I’m not really a group project kind of guy, and I’m not big on forming the kinds of plans that start with “if we all just…” (No good plan starts with those words)

What I can do is invite you to reframe how you look at and evaluate technology. I can invite you to stop viewing prototypes and PoCs as victories or proof of much of anything. I can invite you to stop evaluating technology based on whether it can accomplish something and to instead evaluate it based on whether it can accomplish something so reliably it becomes boring. And I can invite you to look at every technology in your life and ask “does this permanently solve a problem I have?”

Now when I’m talking about permanence here, I’m not trying to suggest that something should never fail to be considered a quality-of-life improvement. If I truly had my coffee problem permanently solved with the caveat that I’d have to swap machines every 7 years, that’s close enough permanent to be genuine solveware. It’s when the cycle time slides backwards, the maintenance overhead gets higher, the useless features mount, and the ads start, that we slide back towards facadeware, where the thing creates more novel problems for me than it actually solves.

I’m also not suggesting that all problem-solution pairs have a duration of “forever.” Maybe my doctor will tell me to quit caffeine this year, in which case I might have been better off with some kind of coffee delivery SaaS thing. Sometimes bridge solutions work, and some problems are ephemeral.

But using judgement to navigate those caveats, you can still start to think about technology less as an assorted bag of features, and more as a way to eliminate cognitive overhead in your life and shorten your todo list. At least, that’s what technology should do. So ask yourself about your various subscriptions and gadgets, are they actually succeeding in solving a valid problem in your life, today, and on an ongoing basis? Or are they just making your problems recur, multiply, and evolve?

If it’s the latter, toss them. Demand more.

Alright, that’s enough words for now. I’m enjoying picking up the digital pen again and have already started on a facadeware taxonomy. After that, I’ll have developed the lexicon to properly tell the tale of my Jeep Grand Cherokee, which is essentially a mobile museum of facadeware.

Coda: What I’ve Been Up To, for Those Interested

If you’re still reading, or if you skipped down here out of curiosity, here’s my situation and why content here has been sparse. My wife and I (and eventually our son) have been digital nomads for the last 10 years. We’ve done that while retaining a lake house, where we would usually spend summers, and then we’re roam the US in the winter. Usually warm parts of the US.

That lifestyle has historically been compatible with running our marketing service business, Hit Subscribe. But over the last year a few things have all kind of piled up together. The most important one is that our son is reaching Kindergarten age, so it’s time to grow up and settle down. 2025 has thus had us shopping for a permanent home and navigating those logistics, eventually deciding on the Pheonix metro area.

On top of that, we made the decision to convert our lake house into a vacation rental, rather than trekking all the way back every summer and spending time in Michigan. So late summer and fall were spent moving our things out of the lake house, living in a nearby AirBNB, and doing the work to convert the house to a rental. Then, after 2 solid months of that, we hauled and shipped everything we owned to Pheonix, moving in here on December 1st, and arriving with 0 furniture. _ _So the last month and a half has been furnishing the house, organizing, unpacking, and all that fun stuff.

And even more on top of all of that, we’ve navigated a pretty serious expansion of the Hit Subscribe offering ladder, bringing a product to market in addition to the business’s traditional services. This required a shift in both the nature of the work that we were doing, and some reorganization of the business itself.

So as you can probably imagine, I haven’t had a lot of time to blog, even if rants have bubbled up inside of me from time to time, with no outlet. But I’m now somewhat settled and hoping to change that.

The Awesome Power of Self-Deprecation in ContentOps

Erik Dietrich — Thu, 02 Oct 2025 17:30:27 +0000

(Editorial note: I originally wrote this post over on the Hit Subscribe blog. I’ll be cross-posting anything I think this audience might find interesting and also started a SubStack to which I’ll syndicate marketing-related content.)

I promise you that I'm going to make some grammar mistakes and maybe even factual errors in this post. Well, promise might be strong. But it's quite likely at least.

The reason, dear reader, is that I simply don't care enough to remedy that ostensibly bad situation. That, and the fact that I read at a 5th-grade level on a good day, combine to deliver you a wholly and unapologetically unpolished experience, should you read on.

The Inline Self-Deprecation Example

Real quick, let's go meta.

What I just did there is something that I do all the time when writing, and I do it reflexively, without really thinking. I self-deprecate because it's kind of fun, and come on, we shouldn't really take ourselves too seriously. But beyond that, what I did actually serves a pretty significant purpose from an operations and efficiency perspective.

I neatly eliminated the need for at least one quality assurance step (and some person-hours) in my content production.

To wit, it's now not super important that I have an editor take a grammar pass through this, nor that I find some flavor of SME to fact check. Why would I bother? I've already inoculated against the critique of "but you did a bad grammar!" and against the critique of "that is factually incorrect, sir!"

Imagine how stupid one of those comments would look in the comments section when I not only hinted at, but practically promised, those outcomes.

I didn't need to pay an editor, and I didn't need to pay a QA SME. I just needed to explain that I don't care enough about those things to spend that time and money.

Generalizing to B2B Content Ops

Before I go on, I want to be clear that I'm not advocating that B2B content operations adopt this exact approach and preface every piece of content with, "I don't care if there are grammar mistakes and I'm an idiot, but, anyway, read about our recent rebrand!" I have a readership, an established style, and a certain voice. So I can get away with this specific tactic for reasons that are probably beyond the scope of this post.

What I was doing to this point is creating a vivid example of self-deprecation and the power that it can have on managing reader expectations. For the rest of the post, I'm going to lay out some tactics that you can use in B2B contexts to achieve the same outcome: minimizing spend on (often futile) quality assurance gates and un-bottlenecking your content production.

Understand that what I'm advocating for isn't laziness, but cost savings and efficiency. Every reviewer you add to a content ops process dramatically slows down content production, increases staffing costs and has diminishing, if not negative, returns. And the famous "duty calls" XKCD reviewer (let's call him Simon Cowell, or Simon, for short) is not who you want to optimize your spend for.

So the question you really want to answer is:

How do we comfortably produce content with minimal gatekeeping, fear-based steps?

The rest of this post is a series of tactics to help answer that question, and that are perfectly viable in B2B scenarios. I'm going to organize them loosely from least to most exotic, in terms of the optics among your peers.

1. Establish a "Notes from the Field" Tone

First off, let me briefly caveat that when I talk about tactics, like "establish a tone," I'm talking about the particular corner of the site you own. So if you are responsible for your company's "learn" portion of the site, I'm talking about establishing a tone for that portion of the site.

Therefore, in this first case, I'm talking about establishing a "notes from the field" tone for, say, "blog" or "learn."

Tonally, this means that you essentially adopt the mindset of a journalist or someone live blogging an event. That doesn't mean unprofessional or unpolished, exactly, but rather that you are going to err on the side of shipping quickly, since you want to get information out in a timely fashion. You can even caveat it with a footer or side gutter note along the lines of:

“Think of [section] as our lab notebook: informal, evolving, and occasionally messy -- but always authentic.”

Setting that tone abstractly or literally, with a caveat, neatly defangs nitpickers both internally and externally. Poor Simon can join his partner in bed.

2. "If you Find Errors in this Post, Please Let Us Know"

In a similar vein, you can simply include an italicized note at the top or bottom of each post inviting readers to submit errata. Like the last tactic, this establishes a disclaimer that there may be errors, but rather than the shruggy guy as your response, you're deputizing critics as contributors.

There is some subtlety here to note.

First of all, if you're going to do this you need to enable comments or a submission form on the content itself. If you can't or won't do that, you should position the caveat in your distribution channel rather than on the site itself. It'd be a disingenuous look to invite critique while providing no means to actually do so.

And beyond that, you need to understand that if you invite this and you start to get traffic, you're going to receive plenty of errata. You're inviting Simon to tell you everything that's wrong with your content, and that's kind of Simon's specialty. This can actually be a great way to drive engagement, but it's also extremely labor-intensive because Simon will sour on you in a hurry if his notes go unheeded.

3. Establish a Jokey, Not-Totally-Serious Tone

Now we arrive at the thing that I'm doing. You too can do it, dear reader! Er, well, kinda. Probably.

This is a solid tactic, but it also has some subtleties to navigate.

First and foremost, it's much easier for a solo creator to establish a jokey tone (e.g. me in my column on this and other sites) than it is for a group to agree on this tone. In other words, agreeing on and executing a group sense of humor is going to be pretty tough. So this tactic becomes less and less feasible with each content contributor to the site.

And I'd generally advise you not to try to somehow standardize humor, sarcasm, jokester-ism, and self-deprecation. You'll wind up looking like someone wearing an "It's Wine-O-Clock" T-shirt to advertise, "tee-hee, I'm silly and a little naughty, please believe me about that."

The other issue to contend with is that, unlike the rest of this advice, you can't really disclaim this one. I mean, I guess you could try to have a note that said something like "we don't take ourselves too seriously," but I'm having trouble picturing that coming off as anything other than weird and try-hard.

With this tactic, you're going to have to put in the work to actually establish that through tone of content and rapport with the readership. And that is, legitimately, a good bit of work. I've achieved this myself, through the not-low-low effort path of 15 years of blogging and thousands of published posts.

4. Brand Firewall through Guest and Community Bylines

Let's switch gears a little now and look at a different interpretation of self-deprecation. Rather than commentary on the content itself, we can look at who is writing the content.

Now I want to be clear that I'm not saying that an external contributor is somehow inferior to someone in your organization. What I am saying is that enlisting outside contributions and being quite public about it is an instant trigger for everyone to get a lot less precious about the content.

If everything you publish on your site has the generic site byline or, worse from a review perspective, an executive's byline, you're presenting everything you publish as representative of the company and its execs. Not only does this position every Simon critique on reddit as an assault not on the content, but the company itself, but it also invites performative content nonsense and thus highly inefficient content production. Every piece becomes a master's thesis to defend.

You can generally avoid this issue by diversifying the bylines to various staff members, thus providing the theoretical optical escape hatch of the brand saying "well, that was just Bill the intern, and Bill's views do not reflect our brand's." And you don't necessarily need to get into the dirty business of throwing employees under the bus -- the reader will infer this to some degree.

But you can make that degree "very high" if you want, by casting a much wider contribution net. Stand up a "write for us" page and slap a guest byline on contributor articles. You can then have disclaimers on that page or on the content itself saying something along the lines of

"This is a guest article from Simon Cowell. We love to provide a platform for contributors of all backgrounds and experience levels to share their tips and opinions, so please write for us (linked) if you're interested in contributing yourself."

This is a nice message and a nice policy. It's also a very effective way to say "our brand didn't directly produce this particular piece of content and contributor opinions and errata are their own."

5. Stand Up a Property or Microsite

The last tactic I'll mention is likely the hardest to sell. In my experience, it simply doesn't compute for a lot of people, even though I personally think way more people should take advantage of it.

I'm talking about establishing a secondary, community website that isn't directly associated with your brand. For instance, Hit Subscribe owns a community site and content lab called "Make Me a Programmer." (It's actually the site we use in our public demo of Osiris).

On that site, we can publish whatever we want, without concern about brand perception. As an example, I ChatGPT-ed up some blog posts verbatim on that site, simply to see how they would perform in search compared to human-written posts. I... probably wouldn't have done that on this site. Simon would have really let me have it, jeopardizing my long-standing policy of completely ignoring any Simons I encounter.

When B2B brands do this, it tends to take one of two formats:

Microsite like makemeaprogrammer.
Media sites like TechBeacon, back when it was owned by Hewlett Packard.

In either case, the owning brand typically presents itself as a top-level sponsor of the subsidiary, thus creating an even larger moat/firewall for the brand than simply disclaiming guest contributors. The reason I like this play so much is that you can instrument the property with analytics, marketing automation, and CTAs to your heart's content. So you actually wind up losing very little in terms of your ability to qualify leads, less of course the diluted domain authority and cross-domain jumping for CTAs.

That said, in my experience this downside is typically an order of magnitude less than the downside of fretting over content until you simply don't produce any, and all of the content people get RIF-ed (which happens a lot). Or from a less personnel and human perspective, it's simply better business to produce content at 80% effectiveness and 100% efficiency than 100% effectiveness and 5% efficiency.

The Likely Impact and Benefit

Given that volume channels look like hockey sticks (ala compounding interest), delay matters. A lot. And you can assume that each reviewer adds a roughly exponential-flavored delay, meaning production, post-draft, per reviewer will look, at scale, something like this:

0 Reviewers: 0 time
1 Reviewer: a few days
2 Reviewers: 1-2 weeks
3 Reviewers: 3-4 weeks

Exponential-ish delay as a draft factor on an (initially) exponential-ish channel is a disaster. Each of these reviewers, years out, will likely cost you hundreds of thousands of visits and hundreds of qualified lead visitors. That's a massive cost.

Now the fact that it's a massive cost doesn't, ipso facto, mean it isn't worth it. You might want this type of review on the occasional piece of high leverage content or, theoretically even at scale in certain instances, like high ticket (7+ figure) services. What it does mean is that you should go into it very skeptically and look for all possible alternatives to avoid incurring this cost.

What I've presented here is an array of such alternatives, and I hope you find some of them useful. And I hope you get your leads (and sanity) back.

Or not. Whatever, what do I know? I'm just some dope that probably forgot an Oxford comma in this post, so caveat emptor.

Surviving the Great Commoditizer: Stop Getting ‘Good’ at ChatGPT

Erik Dietrich — Thu, 12 Jun 2025 16:42:22 +0000

I know, it's been a while. For anyone wondering if I'd given up the blogging habit, I haven't. I just forgot how to read for a bit.

Luckily, however, I have a 4-year-old that loves Dr Seuss, so that's gotten me back on track and no worse for the wear, except for my new penchant to follow people around like an absolute maniac, trying to get them to eat eggs and ham.

Instead of returning to form with one of the many productive tutorials I have in mind, today I rant. But I think it will be productive and even help some of you reading.

I'm going to do a deep-dive on why I think getting 'good' at ChatGPT (my stand-in for all LLM techs) isn't the flex you might think, and why it's quite likely actively bad for your career. But I'll also offer my take on what to do instead, that will be good for your career.

Before that, however, we've got a lot of ground to cover about who, exactly, this advice is for (digital technicians) and how, exactly, commoditization works in the form of a commoditization lifecycle.

Caveat 1: "Life-Good" vs "Career-Good"

But before either of those caveats, let me caveat the idea of "don't get good."

In a vacuum, being good at something is better than not being good at something, and ChatGPT is no exception. But career development doesn't take place in a vacuum.

To understand the distinction, ask yourself whether you're good at shoveling dirt. Are you completely inept? Okay at it, you guess? A shoveling craftsperson?

In a vacuum, if you could wave a magic wand and be one of these 3 things, you'd obviously choose the latter. Who wouldn't?

And that skill might even matter to your life. If you have 15 minutes before the police arrive and you need to bury some critical evidence, then being the Michelangelo of shoveling may represent the single most important skill you ever acquire in your life.

But that doesn't mean you should try to define your career around it, or even involve it in your career as a first-class goal.

Caveat 2: Technicians and Their Meritocracy Mythology

Speaking of careers and goals, let's define the term "technician." I'm using this term, as coined by Michael Gerber in his book, the E-Myth, Revisited, about entrepreneurship. Here's a longer read about the personalities, but briefly:

Entrepreneur is the visionary that looks at the future, imagines the possible, and strikes deals on behalf of the organization.
Manager is the planner, who minds the P&L and looks to maintain a stable and sustainable status quo.
Technician is the doer, who values craft and tends to live by the motto, "if it's worth doing, it's worth doing right."

Gerber's book is a fascinating and eye-opening read (if a little woo-woo at the end for my personal taste) and I recommend it. But the tl;dr of the early chapters is that most people who start businesses or freelance practices aren't really entrepreneurs; they're technicians who have an "entrepreneurial seizure," usually of the form "you idiots are all doing the thing wrong, so I quit and I'm going to go off on my own and do the thing the right way."

For our purposes today, the manager and entrepreneur aren't relevant, mainly because neither archetype is in danger of LLM-flavored commoditization. But the technician -- especially the digital technician -- sure is.

To make it concrete, technicians are, broadly, individual contributors (ICs) that sell labor in the market and create concrete deliverables or, at least, billable services. Think software developers, content writers, graphic designers, accountants, etc.

Another way to think of technicians is as people with a (digital) craft. They may or may not celebrate (or, arguably, fetishize) the idea of themselves as craftspeople, but it's generally their mental model for their work.

Busting The Meritocracy Myth: 'Better' is Just "Cheaper, with Extra Steps"

This mental model gives rise to a pervasive, understandable myth about the nature of their work and its value. Here's the myth:

Being good at your craft is economically valuable.

Yes, you're reading that right. I am calling that statement a myth. (I've written about this for years, at length in articles like these, if you want a deep-dive).

To demonstrate, rather than lengthy explanations about diminishing marginal returns or game theory around fungible labor, here's a realistic hypothetical conversation. These days a lot of my readers are marketers, so that might go over better.

Client: why should I pay you for {blog post, code, graphics, etc} when I can find someone on Fiverr to do it for half the cost!?

Technician: well, you see, because I'm better than they are at the thing!

Client: who cares?

Technician: you should, because if they do it badly, then you're going to need to hire me anyway to do it right, and it'll take longer and cost more.

Client: Oh, so in a plot twist, you're actually the cheapest option from a total cost of ownership perspective -- sold!

Technician: Uhh... wait a --

Client: Pro tip, next time just say immediately you're the cheapest.

This understanding is critical framing for the rest of what I'm going to go on to talk about. This "hey, wait a minute" fusion of "cheap" and "good" is one of the main tells that your labor is approaching the event horizon around the black of hole of commoditization. And you, dear reader, are being spaghetiffied without realizing it.

Context: The Commoditization Lifecycle

You're in trouble, but the beauty of you sitting at the event horizon is that you're absolutely not going anywhere (literally, physics-wise, from an observer perspective). So let's add one more bit context before diving into the problem with where you're positioned with respect to the great commoditizer, ChatGPT.

Going a bit meta, here's an AI-synthesized definition of commoditization that works well for the purposes of this post.

[A] process where products or services become increasingly similar, interchangeable, and price-driven, losing their unique features and value.

With digital technicians, we're talking specifically about digital services and labor. And those don't become immediately commoditized. Instead, it happens gradually over the course of time in a process that I'll call the commoditization lifecycle.

Here are the stages of that lifecycle, with respect to the nature of the work done by humans, thus producing labor and services.

	Nature of Work	Who	Example
1.	Innovation	Entrepreneur	Founding "Uber, but for Socks"
2.	Skilled Labor	Technician	Programming
3.	Unskilled Labor	Virtual Assistant (VA)	Situational Data Entry
4.	None	A Computer	Wix/Weebly/WordPress

Website Construction: A Full Lifecycle Example

To really understand how this plays out over time, let's consider the evolution of work from innovation all the way down to complete automation. And for my example here, I'm going to zoom in on the Wix/Weebly/Wordpress (Webflow -- why do all these things start with 'W'?) example.

In the late 1990s, when the internet was a baby, building a website for commercial purposes was the wild west, with no playbook for success and tons of risk.
By the mid 2000s, building a website was something a skilled software engineer, like me at the time, was doing. Barriers to entry were high -- I had 2 CS degrees -- and the labor required a good bit of expertise and judgement. Not for the unskilled or faint of heart.
By the 2010s, CRUD frameworks like Rails and DIY options like Wordpress had dramatically lowered the barriers to entry and allowed self-serve options, increasingly commoditizing the labor of building a website.
Today, I have no idea why anyone would "build a website" in the way they used to in the 90s and 2000s, unless they were nostalgic.

Over the course of roughly a generation, the skillset and labor around "build a website" underwent the entire commoditization lifecycle.

Interestingly, programming itself stayed mostly in row (2), with a dash of (3), as this took place. But this is because programmers stayed one jump ahead of the commoditization breadline by moving on to solve other, distinct problems. This programmer-breadline dynamic is going to be very important to remember later, when I'm explaining the exact problem with getting good at ChatGPT as copium.

Good business, by the way, is what drives this cycle. If you run a business or an ops group, your charter should always involve moving work down the ladder, innovating, SOP-ing it, and then making your SOPs reliable and predictable enough for automation.

The Great Commoditizer: What ChatGPT Actually Represents

Now that we have the lexicon to look directly at the problem, let's finally talk about ChatGPT.

Going back to the physics metaphor around black holes, think of historical commoditization as a star with a gravitational pull. As a category of work becomes increasingly mainstream and SOP-ed out, that work slides down from (1) to (4) in the lifecycle, subject to the gravitational pull of commoditization.

ChatGPT has turned that star from a source of gravitational force into a much more powerful black hole of commoditization from which it's harder (and eventually impossible) to escape.

Crucially, the black hole can reach WAY further up the skill chain, insta-commoditizing knowledge work tasks that used to be 10-20 years away from commoditization at any given time. The moat that had persisted around traditional digital technician skillsets was vaporized, and, with it, the traditional tactics for staying in the relatively comfortable stage 2 of the lifecycle.

What ChatGPT really represents is the smashing together of stages 2-4, leaving only stage 1. (At least, on the surface, and in current public perception. This ignores the current, glaring weakness that these techs aren't actually very effective in a lot of stage 2 work, currently.)

An Own-Goal: What Getting Good at ChatGPT Actually Represents

So let's think, then, about what becoming "good" at operating ChatGPT represents, given that ChatGPT is essentially a massive, rapid technician-commoditization engine that (theoretically) allows anyone to self-serve at what used to be your skilled labor.

To get "good" at using ChatGPT to execute your tradecraft is thus to get good at commoditizing your own labor and your craft. You're becoming an expert in reducing the value of your own labor to $0.

And, while that might be an absolutely savage thing to do if you intend to do it, I don't imagine that most technician-crafter types flip from "I want to be a writer" to "I want to automate writers and writing out of existence." To illustrate the own-goal, let's do another hypothetical conversation between Achilles and the tortoise.

Technician: check it out, I'm getting REALLY good at ChatGPT!

Client: I don't care about that even a little, but thanks.

Technician: you should, because with my new skills, I'm writing blog posts for you twice as fast!

Client: Sweet! Why didn't you just tell me you were reducing your prices by 50 percent?!

Technician: Wait, no --

Client: I was going to fire you anyway, since who pays $100 per hour blogging labor anymore, amirite? But now that my $100 for your hour gets me 2 blog posts at $50 each, I'll fire you a little later. Making your work half as valuable was a great move! I mean, a great move for me, but still.

(Admittedly, part of the problem here is attributable to the absurdly perverse incentives created by hourly billing, but the commoditization issue remains. Read more about hourly billing on Jonathan Stark's site, if you want to go down that rabbit hole.)

Think back to the earlier red flag of your labor's commoditization, wherein "good" and "cheap" fuse together. For increasingly commoditized labor (e.g. participating in RFPs), the "good means cheap" paradox has always existed.

But adding the great commoditizer, ChatGPT to the mix, you take that dynamic, put it on skis, and shoot it down the mountain with a missile launcher. You're proudly showing off how easy it is for anyone to do your erstwhile job themselves with just a smidge of "prompt engineering" as the only, tiny barrier to entry.

Getting "Good" Won't "Save" You, Either

20 years ago, when I was a fresh-faced software engineer, and before years of management consulting eradicated every last bit of humanity from my soul, I was the engineering lead on a piece of pre-Workato software that connected mail sorting billable data to back-office accounting systems. This was a traveling act, with sales engineering responsibilities included in my role.

I can recall going out to client sites all over the US and supporting the installs, including helping train customer data entry personnel in using the software. Gradually my professional innocence died as I realized that these people were all going to be laid off. But I do recall that they reacted in one of two ways:

Probably 75% of them were completely checked out, either realizing they were going to be laid off or not really caring about anything that happened in their day to day.
The other 25% were absolutely dialed in and committed to learning the tech. Their jobs were also going to not exist anymore, their enthusiasm notwithstanding, but to this day I like to hope that they at least landed somewhere productive at the shops.

The lesson here, dear reader, is that the great commoditizer is going to eat you, whether you defiantly flip it the bird or offer to help round up others to toil in its sugar caves. So if you're going to go out, you might as well go out like John Henry, dying with hammer in your hand.

Why LLM Proficiency Superficially Seems Like a Marketable Skill

Aside from the anthropomorphic appeasement angle embodied by Kent Brockman, there is another, much less obtuse, reason to think that proficiency at the great commoditizer is a good career hedge. At this point I'm going to fire Chekov's gun and call back to when I said programmers staying ahead of the breadline would be important.

Your mental model for today's knowledge worker and ChatGPT is likely the programmer. But where the programmer's canvas was "geek stuff" today's "prompt engineer" has a canvas of their own tradecraft, or, I guess, of English language.

Today's "prompt engineer" likely views their role with the tech as similar to the role of a programmer with a programming language. And this understandable parallel is doubtless buoyed by the rise of the concept of "agentic AI," wherein the user becomes a sort of sorcerer's apprentice, flailing their arms around casting spells and hurling agents at assorted workflows in a symphony of... something.

So, the logic goes, today's LLM operator is the 90s programmer. And, just as the 90s would have been a good time to learn software engineering, the 2020s are a good time to learn prompt engineering.

Why LLM Proficiency Isn't, Or at Least Shouldn't Be, a Marketable Skill

I'm using "prompt engineer" a bit tongue-in-cheek, since, if it hasn't already, the world is almost certainly going to figure out that this is kind of a terrible idea when you actually unpack it. And that's why, broadly speaking, ChatGPT proficiency in general doesn't actually turn out to be a good idea, even if you set out to commoditize someone else's tradecraft rather than your own.

Notwithstanding superficial similarities, "prompt engineering" or ChatGPT operating, is actually nothing like programming, now, or ever.

The AI Companies Won't Like the Optics

First of all, the AI companies themselves would probably be passively hostile to you touting this as a skill set. I mean, think about it. This would be like you standing outside of Starbucks, telling people that you're a coffee ordering engineer, and you speak the secret in-group language about Ventis and Double Mocha Whatevers, and you provide a valuable service helping bridge the gap between baristas and consumers.

Before we even get to this being an incredibly weak value proposition, don't you imagine Starbucks would have something to say about this?

"Yeah, that's not a thing, our baristas can communicate with our customers thanks."

As a prompt engineer, you would encounter a two-faced channel partner, who would want you to be a power-user and evangelist, but who would hate the implication of your existence: that its product needs some kind of translator when the product is intended for the end user.

Programming Is Translating, Prompt Engineering... Isn't

But let's now dive into the weak value proposition of this skillset compared to the programmers of yore.

Programmers, at their core, are translators. They translate messy natural language into precise constructs in first order languages and boolean/propositional logic and vice-versa. You tell them in English that you want the computer to go beep-boop, and they translate that into the Javascript and/or eventual assembly code that makes the beeps and boops.

This sort of translation doesn't happen with LLM operator "skillsets" or prompt engineering. You'd just be translating English into... other, slightly different English, and vice versa. If any value proposition exists here at all, it's the weakest imaginable sauce. OpenAI isn't designing ChatGPT to need you to be good at it for other people; it's designing it to be good at itself.

2010s Zeitgeist Aside, the World Tolerated More Than Celebrated Programmers

It's understandable to confuse programmers and ChatGPT operators, especially now that programming itself is becoming commoditized. But you need to recognize that, historically, the world tolerated programmers more than wanted them.

They were Poindexter, and Wall Street finance bros would keep Poindexter around to make trades happen faster because they didn't know how to do it themselves.

They would yell at him, "in ENGLISH Poindexter," and make fun of him and hire project managers to deal with him so that they didn't have to. Eventually, as this labor became indispensable, a certain geek chic took over, and programmers became the zeitgeist and eventually kingmakers and entrepreneurs in their own right. But at their very core, they were always Poindexter.

Now, with wholesale commoditization of programmers at large and with "vibe coding," the Wall Street finance bros are free of Poindexter, and they can say what they've been wanting to say to Poindexter for a generation: "$%&# off, Poindexter."

I promise you, nobody is looking to replace Poindexter with you, a far, far less necessary Poindexter.

Escaping the Commodification Event Horizon

There is, however, good news. Being good at ChatGPT and going on LinkedIn to be performatively good at ChatGPT aren't your only path forward. Far from it. There are PLENTY of things you can do that don't involve participating in your own commoditization or feeding your own tradecraft to the beast.

Instead of any of that, figure out how to be complementary to it, or, at the very least, orthogonal. And that's what I'll focus on in the last section of this post.

ChatGPT and its brethren are frighteningly and astonishingly good at a lot of things. But they also can't count and keep telling people to eat a few rocks each day, so they're hardly the Utlimate Intelligence of the Hyperion universe. There's still a place for you, along side these techs, doing things they aren't good at or don't help with.

1. Be Strategic

Your first option is of the "simple, not easy" variety. And that is to become strategic in terms of your role within your organizations, or others', as a consultant.

And I'm talking here about actually participating meaningfully in organizational strategy. This is not to be confused with being "strategic" in the LinkedIn sense, where you declare yourself a "strategist."

ICs have a tendency to do this, and IC work has a tendency to drift in this direction via developmental titles and a desire to reward seniority. A software architect is a software developer, but more "strategic" or something. In the content world, people just lazily slap "strategist" onto the end and become a "content strategist," who, presumably, can not only write blog posts, but also brainstorm titles for them.

I'm being flippant to draw a distinction. Strategy, these things are not.

If you want to see whether you're strategic, there's here's an incredibly simple heuristic:

Does anyone pay you, or would they pay you to tell them what to do, with that advice as the sole deliverable?

If the answer is yes (and your advice is actually valuable), you're actually a strategist. As I said, simple, not easy. An exercise for the reader is to brainstorm how to move toward that goal, if you want to get there (though I do have two YouTube channels with all kinds of advice on that topic).

2. Pivot Away from Technician Work

As kind of a corollary, and perhaps a tactic for becoming a strategist, you could simply stop doing technician work. Like the first item, this would function as a voluntary creative constraint and as a forcing function.

If digital technician work is subject to commoditization and you don't want commoditization, stop doing the thing subject to commoditization.

Years and years ago I was subcontracting for a firm that did strategy consulting but was also an app dev body shop. I was onsite at a bank, as a management consultant, helping them answer the age old question "why isn't our agile, agile?" Also there was a team of ~~software engineers~~ consultants.

In an exchange that seemed flippant to me at the time (at least my part of it), one of the software engineers asked me essentially, "we're both consultants, so why do they listen to you and not me?"

My response at the time was something like:

Because you write code for them. As soon as you write code for them, you're not a consultant (player-coach philosophy notwithstanding). You're a developer with an opinion. And they already have an entire department of those.

Like becoming strategic, simple, but not easy. Stop technician-ing. Figure the rest out as you go.

3. Be Genuinely Interesting

Switching gears a little here, the third thing that I'll offer is probably most helpful to people in the marketing org chart, but could help anyone stand out. (I'm really looking at you here, accountants.)

When creating content, you're almost invariably trying to do some combination of two things: educate and entertain. Being interesting, or creating interesting content, tends to heavily focus on the entertain concern, but it can make educational content much stickier.

ChatGPT isn't interesting, at least, not unless the user is getting their jollies by prompting it to sound like John Wayne, or whatever. ChatGPT is basically just the synthesized, median human on the internet, stripped of personality and retrofitted with a different one, artificially. The lift for interesting is entirely on its user.

Not true of you. You can carve out a place being interesting alongside it in the same way you can cultivate a readership in a world full of 101 definitional and guide SEO content.

And you don't need to be a marketer for this, or specialize in content creation. Simply being personally interesting and having novel insights may go a long way for you interpersonally as well.

ChatGPT is only going to answer the questions you ask it. Go forth and answer questions people have yet to know to ask.

4. Be Precise and Detailed, Maybe in Regulatory Fields

Or, you could go in the complete opposite direction. (Now I'm REALLY looking at you, accountants.)

LLMs are fun and sloppy. Sure, they've got their quirks and might randomly tell you to drink bleach when you ask what to do for indigestion after working out, but it's about tomorrow's vision, not today's bugs, amirite?!

Well, I mean, unless you work in a regulated field. I pity the foo' that asks ChatGPT how to handle HIPAA compliance in their customer onboarding and then just does it, or that vibe codes up something on top of a database with PII.

You simply cannot trust ChatGPT to do important things unsupervised. So, position yourself as that supervision. Find a niche where stakeholders depend on you to get it right 11 times out of 10.

5. Cultivate Deep, 10x More than Median, Knowledge

As I probably mentioned earlier once or twice, at its core what these techs are really doing is synthesizing the median knowledge of the internet. And that's a killer application for a lot of things (DIY home improvement, recipes, etc), a mixed bag in a lot of fields, especially with lots of hokum (SEO, wellness advice, etc), and limited in other areas (e.g. cutting edge nuclear physics).

This can be refined somewhat, with smaller models, trained on more highly curated data. But you're still just getting the median of whatever they have available for their training.

So if you become far, far more knowledgeable about a niche topic that's in demand, you'll have a fairly well-defended career fortress. Granted, amassing and maintaining this knowledge may be tough. But presumably you'll start with something about which you are already knowledgeable.

As a simple example, this would apply to me and the ins and outs of staffing content programs. If I were to ask ChatGPT what to bear in mind when starting up a content operation on a $15K per month budget, I'd read through going "yes, okay I guess, yes, nah that's stupid, yes, yes..."

That's your heuristic. Build a knowledge store in which you're confident enough to decide whether ChatGPT is right or whether it's telling people in your field to eat a couple of rocks.

6. Be Reliable

This is similar to the one about being precise, but with more emphasis on the dependability angle, from a delegation perspective.

Personally, I find the concept of "agentic AI" to be kind of wild. Not that I think there's no future in it, but "highly productive, but confidently wrong 10% to 20% of the time with no humility or self-awareness, and doesn't learn from mistakes" is one of the worst imaginable traits in a report to whom you want to delegate anything that matters. Like, I don't think you could engineer an employee I'd be less likely to hire.

So, be that, but without the wrongness. This might be one of the best ways to neatly coexist with the tech -- deploy it for the productivity, and fix the 10% to 20%.

However, I'd like to point out in the broader theme of this post that being good at the tech isn't actually the point, and it isn't actually relevant to your stakeholders. It's an implementation detail. They care that you're both reliable and productive, however you happen to accomplish that.

So seek out situations where the work delegated to you and its correct, prompt completion is important, with no room for slop and hallucinations at the end of the day. High optic, PR type situations come to mind, among others.

7. Simply Be Human

Speaking of PR, there are situations in which simply existing as a human being is a differentiator.

A while back, someone in a Slack community I participate in posted a facepalm story about a CEO somehow being busted using AI to generate a fairly sensitive company-wide communication. I forget the details, but let's just assume it was "In today's fast paced world, you're all fired, clean out your desks; do you like this persona?"

Think for a moment about why this outrages you. It's not because the bot did anything wrong, per se. It's because a bot was the wrong man for the job, in the same way that "some meetings have to be done in person" or "you don't break up with a long term significant other with a text."

There are situations where the use of a bot has bad optics. Find those situations and participate in them as part of your living.

8. Cultivate a Rolodex

Another option for those of you that favor the highly interpersonal is to think about navigating your career in a way that leverages your human connections. And I don't mean this in a scheme-y sense, but rather in the "people person" sense.

For example, an interesting artifact of having spent more than a decade in business for myself, and the majority of that time handling my businesses' sales is that I have an enormous rolodex. If I were going to embark on a market research listening tour for a new offering, I could fill my calendar for literally weeks.

There is no LLM on earth that could replicate that. And it's highly commercially useful, either for my own ventures or if I were to hire on somewhere as an early stage growth or COO type or what have you.

So think about your own rolodex and professional relationships and the part you play in them. What kind of career arc going forward could you build that leans on being a relationship-builder and a people person?

9. Build Intellectual Property and Join the Investor Class

This is another of the simple, but not easy, advice points. Start a business venture.

And no, technicians, for the love of God, please don't make an info product. Those have been bordeline useless commodities for years and there has absolutely never been a worse time to try than now, when a bot can slurp in and plagiarize the whole thing on demand if you setup your robots.txt wrong.

I'm talking about starting a value-driven business.

Technician concerns are the production, and a business is the means of production. To put it bluntly and cynically, when you found a business, the technician labor vs GPT labor goes from an existential career crisis to an implementation detail of your service delivery. I'm not looking to blunder into the political or philosophical here -- I assure you my opinions on those matters are not interesting -- but being the one who makes the decision is inarguably a less precarious position than hoping the day isn't here yet.

There are three things that you can bring to a nascent business: capital, labor, and expertise. If you start with labor (e.g. a services business), you'll generate the other two for yourself over time, and be in a position to spend the rest of your career entering and exiting businesses on your terms.

10. Don't Panic, Ride it Out

Alright, as I bring this thing lumbering to a close, I want to leave you with one last piece of advice. And that is, calm down.

For all of the breathless hype, we're really not at, or anywhere close to, the singularity.

The idea of humans driving cars has been dying for 10 years, and yet I'm still about to drive to pick up a U-Haul.
SEO has been dying for 20 years, and somehow we still have a thriving business delivering services around it.
Mainframe computers have been dying for 50 years, and yet I still have no doubt I could go back to a consulting practice where I helped enterprises navigate risks around them.

If your job dies at the same rate as most things that hypsters and bleeding edge adopters proclaim to be dead, you may well be in danger of dying of old age before your job dies of hype cycle.

Don't get me wrong. The commoditization is real, and it's here, and you'd do well to prepare for it. But that 10% to 20% of details that will {waves hand} be sorted out in the next version often take a whole lot of years and decades worth of versions before they're actually sorted out.

This gives you time to breathe, collect yourself, take a long view, and chart a path away from commoditization. And that is a good idea regardless, because the world itself tends to be a great commoditizer. In our world now, the great commoditizer just has very visible (and peculiarly sphincter-like) branding.

The Gotchas of Building an In-House Observability Platform Using Prometheus

Erik Dietrich — Tue, 29 Oct 2024 12:41:58 +0000

Editorial note: this post was written by the Sawmills team originally posted on the Sawmills blog .

In the era of cloud-native applications and microservices, observability has become a cornerstone of reliable software systems. Prometheus, an open-source monitoring and alerting toolkit, is often the go-to choice for organizations looking to build their own observability platforms. While Prometheus offers a rich feature set and the allure of customization, building an in-house observability platform is fraught with hidden challenges and costs that are not immediately apparent.

In this blog post, we'll delve into the intricacies of building an in-house observability platform using Prometheus. We'll explore when it makes sense to take on this endeavor, when it might be wiser to opt for alternative solutions, the known and unknown challenges you'll face, the hidden costs involved—including the risks associated with high cardinality metrics—and strategies to mitigate the associated risks.

Introduction to Prometheus

Prometheus is an open-source systems monitoring and alerting toolkit originally developed at SoundCloud. It has become a cornerstone in the cloud-native ecosystem, especially when used in conjunction with Kubernetes. Prometheus excels at collecting time-series data, offering a powerful query language (PromQL), and integrating with various third-party tools.

Key Features of Prometheus

Time-Series Data Storage: Efficiently stores metrics data with labels.
PromQL A flexible query language for slicing and dicing collected time series data.
Service Discovery: Automatically discovers services through various mechanisms like Kubernetes APIs.
Alerting: Supports alert definitions and integrates with Alertmanager for notifications

When to Build In-House

Building an in-house observability platform using Prometheus can be advantageous under certain conditions:

1. Customization Needs

Specific Requirements: If your organization has unique monitoring needs that off-the-shelf solutions can't meet.
Integration Capabilities: Seamless integration with proprietary systems and workflows.

2. Cost Considerations

Avoiding Licensing Fees: Prometheus is free to use, which can be appealing for budget-conscious organizations.
Long-Term Savings: Potential for reduced costs over time compared to recurring fees for SaaS solutions.

3. Data Control and Compliance

Security Concerns: Keeping sensitive metrics data within your own infrastructure.
Regulatory Requirements: Meeting stringent compliance standards that require on-premises data storage.

4. Developing Internal Expertise

Skill Building: Fostering in-house talent and expertise in observability.
Innovation Potential: Encouraging a culture of innovation by solving complex problems internally.

When Not to Build In-House

However, building your own observability platform isn't always the best route:

1. Resource Limitations

Time Investment: Developing and maintaining the platform can divert focus from core business activities.
Talent Shortage: Lack of experienced personnel to manage and operate the platform effectively.

2. Total Cost of Ownership

Hidden Expenses: Infrastructure, maintenance, and operational costs can surpass initial expectations.
Opportunity Cost: Resources allocated here might yield better returns if invested elsewhere.

3. Complexity and Maintenance

High Complexity: The intricacies of setting up a scalable, reliable monitoring system can be overwhelming.
Continuous Updates: Ongoing need to update, patch, and secure the system adds to the workload.

4. Scalability Concerns

Performance Bottlenecks: Scaling Prometheus for large environments requires significant effort.
Risk of Downtime: Greater potential for outages if the system isn't managed properly.

Known Challenges

1. Storage Limitations

Local Storage Constraints: Prometheus stores data locally, which can lead to data loss if a node fails.
Scaling Storage Limited: by the storage capacity and performance of individual nodes.

2. Achieving High Availability

Complex Architectures Required: Setting up redundancy involves multiple Prometheus instances and data replication strategies.
Increased Maintenance: More components to manage and monitor.

3. Alerting Complexities

Managing Alert Noise: Without careful tuning, you may experience alert fatigue due to excessive notifications.
Configuration Overhead: Requires meticulous setup to ensure critical alerts aren't missed.

4. Limited Long-Term Data Retention

Short Default Retention: Prometheus defaults to a 15-day data retention period.
Need for External Storage Solutions: Requires integration with systems like Thanos or Cortex for extended retention.

5. Security Limitations

Lack of Built-In Security: Prometheus doesn't offer advanced authentication and authorization out-of-the-box.
Manual Security Implementations: Additional effort needed to secure data in transit and at rest.

Unknown Challenges

1. Evolving Requirements

Changing Business Needs: As your organization grows, your observability requirements may change, necessitating redesigns.
Technology Shifts: New technologies may introduce unforeseen integration challenges.

2. Community Support Variability

Inconsistent Support: Reliance on community support can be risky when dealing with critical issues.
Documentation Gaps: May lack comprehensive guides for complex setups or troubleshooting.

3. Integration Complexities

Custom Development: Integrating with proprietary or less-common systems may require custom solutions.
Data Consistency Issues: Ensuring consistent data across multiple systems can be challenging.

4. Performance Tuning

Non-Optimal Defaults: Default configurations may not suit your specific workload, requiring extensive tuning.
Continuous Optimization: Ongoing effort needed to maintain optimal performance as the system scales.

The Hidden Costs of Prometheus

While Prometheus itself is open-source and free to use, deploying it as part of an in-house observability platform involves several hidden costs that can accumulate over time.

1. Infrastructure Costs

Hardware and Storage Requirements

Scalability Demands Increased: monitoring needs require more computational resources, storage, and memory.
High Availability (HA): Implementing HA doubles or triples infrastructure requirements due to redundant instances.
Network Bandwidth: Collecting metrics from numerous endpoints consumes network resources, potentially necessitating upgrades.

Cloud Expenses

Resource Usage: Cloud deployments incur costs for compute instances, storage, and data transfer.
Data Transfer Fees: High volumes of monitoring data can lead to substantial egress charges.

2. Operational Overhead

Maintenance and Upgrades

Continuous Updates: Regularly updating Prometheus and associated tools to the latest versions demands ongoing effort.
System Monitoring: The observability platform itself requires monitoring to ensure reliability.

Configuration Complexity

Advanced Configurations: Tailoring Prometheus for complex environments requires deep expertise.
Alerting Rules Management: Crafting effective alerting rules is time-consuming and needs regular updates.

3. Scaling Challenges

Performance Tuning

Resource Optimization: Achieving optimal performance involves extensive tuning and testing.
Sharding and Federation: Scaling horizontally introduces additional layers of complexity.

External Tools Integration

Additional Components: Tools like Thanos or Cortex are necessary for scalability but add complexity and costs.
Learning Curve: Each new tool requires time to learn and integrate effectively.

4. Data Retention and Storage Costs

Limited Retention Period

Default Limitations: The default 15-day retention may not meet business or compliance needs.
Extended Storage Needs: Long-term retention requires additional storage solutions.

External Storage Solutions

Implementation Effort: Setting up external storage systems is complex and resource-intensive.
Cost of Storage: Long-term storage incurs additional hardware or cloud storage fees.

5. Security Expenditures

Lack of Native Security Features

Authentication and Authorization: Additional tools or custom solutions are needed to secure Prometheus.
Encryption: Implementing encryption for data at rest and in transit adds complexity.

Compliance Measures

Regulatory Compliance: Ensuring the observability platform meets compliance standards can be costly.

6. Staffing and Expertise

Talent Acquisition

Hiring Specialists: Experienced Prometheus engineers command high salaries due to demand.
Consultancy Fees: External consultants are expensive but may be necessary for complex implementations.

Training Existing Staff

Learning Curve: Training staff diverts time from other productive activities.
Ongoing Education: Continuous learning is required to keep up with updates and best practices.

7. Integration and Custom Development

Third-Party Integrations

Custom Solutions:
API Management:

Dashboarding and Visualization

Additional Tools Needed:

8. Alert Management Overhead

Alert Fatigue

Signal-to-Noise Ratio: Excessive alerts can overwhelm teams, leading to important alerts being missed.
Fine-Tuning Required: Significant effort is needed to configure alerts properly.

On-Call Burden

Increased Stress: Poorly managed alerts increase stress and can affect team morale.
Operational Costs: More alerts can lead to higher operational expenses due to increased incident responses.

9. Opportunity Costs

Focus Diversion

Core Business Neglect: Time spent on the observability platform could be used for core product development.
Time-to-Market Delays: Diverting resources may delay the launch of revenue-generating features.

Innovation Lag

Technology Adoption: Focusing internally may cause delays in adopting new, more efficient technologies.

10. Community and Support Limitations

Limited Official Support

No Vendor Support: Reliance on community support can be risky for critical systems.
Documentation Gaps: May lack detailed documentation for advanced configurations.

Reliance on Community Contributions

Unpredictable Roadmap: Dependence on the community for updates can be uncertain.
Compatibility Issues: Updates may not align with your custom setup, requiring additional work.
Unpredictable Roadmap: Dependence on the community for updates can be uncertain.
Compatibility Issues: Updates may not align with your custom setup, requiring additional work.

11. Legal and Compliance Risks

License Compliance

Understanding Licenses: Integrations may involve various open-source licenses requiring careful management.
Intellectual Property Concerns: Mismanagement can lead to legal issues.

12. Hidden Bugs and Reliability Issues

Testing Requirements

Quality Assurance: Ensuring reliability demands rigorous testing efforts.
Bug Fixes: May require diving into the codebase, which is time-consuming.

Downtime Cost

System Outages: Failures in the observability platform can lead to undetected issues elsewhere.
Recovery Efforts: Restoring services can be resource-intensive.

13. High Cardinality Risks

High cardinality refers to metrics that have a large number of unique label combinations. While labels in Prometheus are powerful for slicing and dicing data, they can introduce significant challenges when not managed properly.

Impact on Availability

Performance Degradation: High cardinality can lead to increased memory usage and CPU load, causing Prometheus servers to become unresponsive or crash.
Slow Queries: PromQL queries over high-cardinality metrics can be slow, impacting dashboard performance and alerting delays.

Increased Costs

Resource Consumption: More unique metrics require more storage space and processing power, leading to higher infrastructure costs.
Scaling Requirements: To handle high cardinality, you may need to scale your Prometheus setup horizontally, adding complexity and expense.

Management Challenges

Difficult to Monitor: Keeping track of which metrics are contributing to high cardinality can be challenging.
Troubleshooting Overhead: Identifying and resolving issues caused by high cardinality consumes valuable time and resources.

Risk Mitigation Strategies

To navigate these challenges and hidden costs, consider the following strategies:

1. Start Small and Scale Gradually

Pilot Projects: Begin with a limited scope to understand the complexities involved.
Incremental Scaling: Expand the platform as your team's expertise grows.

2. Leverage Managed Services

Hybrid Approach: Use managed Prometheus services to offload some operational burdens.
Cloud-Native Solutions: Consider services like Amazon Managed Service for Prometheus.

3. Invest in Training and Talent

Skill Development: Provide comprehensive training for your team.
Hire Experts: Bring in experienced personnel to guide the implementation.

4. Utilize Complementary Tools

Long-Term Storage: Integrate with Thanos or Cortex for scalable storage solutions.
Visualization Tools: Use Grafana for advanced dashboards and analytics.

5. Automate and Standardize

Infrastructure as Code: Employ tools like Terraform or Ansible for consistent deployments.
Continuous Integration/Continuous Deployment (CI/CD): Automate testing and deployments.

6. Implement Security Best Practices

Secure Configurations: Use reverse proxies, service meshes, or OAuth proxies for authentication.
Compliance Audits: Regularly audit the system for compliance with security standards.

7. Manage High Cardinality

Label Best Practices: Limit the use of labels that have high cardinality, such as user IDs or timestamps.
Metric Aggregation: Pre-aggregate metrics where possible to reduce the number of unique series.
Monitoring Tools: Use tools to analyze and report on metric cardinality to identify and address issues early.

8. Engage with the Community

Active Participation: Stay involved with the Prometheus community for updates and support.
Contribute Back: Sharing your solutions can improve the ecosystem and build goodwill.

Conclusion

Building an in-house observability platform using Prometheus offers the potential for customization and control, but it's essential to be aware of the hidden costs and challenges involved. From infrastructure expenses to operational overhead and security considerations, the total cost of ownership can be substantial. High cardinality metrics, in particular, pose significant risks to both the availability and cost-effectiveness of your Prometheus deployment.

Before embarking on this journey, conduct a thorough cost-benefit analysis that accounts for these hidden costs. Consider whether your organization has the resources and expertise to manage these challenges effectively. By starting small, leveraging managed services, investing in talent, and adopting best practices—including careful management of metric cardinality—you can mitigate risks and build a robust observability platform that aligns with your organization's needs.

Remember, the goal of observability is to enhance your ability to understand and improve your systems—not to become a drain on resources. Choose the path that best supports your organization's strategic objectives while providing the insights you need to succeed.

Organic Traffic Recovery: How to Win SERPs and Influence Execs

Erik Dietrich — Wed, 28 Aug 2024 02:20:26 +0000

In the last few months, I've been burning the midnight oil. By day, I run Hit Subscribe. But by night and weekend, I've buried myself in a sea of client analytics data, building out our content performance monitoring alpha offering.

I say this not to complain. After years of pretending to know what I'm doing in marketing, it's fun to return to my roots of pretending to know what I'm doing in software engineering. I mention the midnight oil because it has served as fuel for deep, interesting insights into refreshing content and traffic recovery.

And today I want to offer up those insights to you in the form of a clear, actionable traffic recovery playbook.

Setting the Scene: What Happened to Our Traffic?

Imagine that you're responsible for content on your site and your organic traffic graph looks like this.

Sooner or later, you're going to have an uncomfortable conversation about how and why you've presided over a 40% traffic decline. From my outsider's perspective, this most commonly occurs following an acquisition or perhaps a change in leadership. After obligatory pleasantries, one of your first professional encounters is explaining this graph.

There's a pretty good chance that you have many valid reasons. Someone cut the content budget. A staff writer quit and the backfill took forever. The recent site redesign performs as well as a walrus on a unicycle.

But even as you say these things, they'll sound like excuses to you. And they'll absolutely sound like excuses to the other party.

So here's what you say instead:

I can do a detailed postmortem write-up on the traffic performance if you want. But if you're interested, I have an actionable plan for how to recover the traffic and I can show you that.

These two sentences will absolutely and completely reset the conversation. You just need to be able to deliver on the actionable plan. And that's what I'm going to hand to you in the following sections, drawing on our now-unfair advantage of tons and tons of data.

Traffic Recovery in Five Choreographed Steps

To turn "down and to the right" into "up and to the right," here are five things that you should do in parallel, in priority order.

Fix acute, technical problems afflicting traffic-earning URLs.
Execute touch-up refreshes on slowly declining URLs.
Plan and execute comprehensive refreshes on underperforming URLs.
Consolidate and de-cannibalize cannibalizing URLs.
Plan and execute new content.

And here's what that looks like in spreadsheet form, with more detail.

Here's a quick legend for the columns in the sheet.

URL signal is what you're observing in terms of the URL's traffic pattern.
Effort is the relative amount of combined person-hours that goes into each of these.
Skills are the skillsets you'll need to bring to bear to properly execute the tactic.
Who is a loose capture of the role of the person required.
Traffic payoff is when you can expect results. I'm basing this on a lot of empirical measurement at this point.
Time to rank is how long it takes new content to rank in the upper half of target SERPs (and thus earn significant traffic). The last three tactics all vary based on time to rank.

If you've never measured time to rank, you can ballpark it based on your site's domain authority. That's in tab 2 of the sheet, but here's what it looks like:

Prerequisites: What You Need

Before going through each of these steps in detail, let's look briefly at what you need in order to make this happen.

In terms of skill sets, you'll need to have at your disposal someone with decent working knowledge of technical SEO (in the event of acute problems), someone savvy about keyword research and ranking, and a subject matter expert (SME) in whatever your content is about. Depending on whether there are acute problems and what those are, you also might want your web developer handy.

In terms of tooling, you really just need some kind of analytics installed on your site. The dashboarding I'm building acts (by design) as an easy-mode cheat code for this, but you can make it happen with basic analytics and some determination. You just need the ability to examine traffic to your individual URLs over time.

I wouldn't rely on an external tool for traffic data. Something like Ahrefs is handy for analyzing trends, but it's too imprecise here, where the details matter. A tool like that, with SEO audit functionality built in, might help you with any acute technical SEO triage.

Executing the Recovery Plan

Now on to execution. I would suggest doing all of these things in parallel, if you have the bandwidth. But I have prioritized them in order of what will bring the most traffic the fastest.

(I realize "acute problems" and "touch-up refresh" don't strictly follow that order, but acute problems can sandbag all of the other items, so you want to do those first if they exist.)

1. Fix Acute Problems

First and foremost, you should fix acute problems with your site. These can, of course, take the form of shotgun-foot issues like your site being down or changing your entire URL scheme without redirects. But it often takes subtler forms and sometimes only happens to one or a handful of URLs.

If you're looking at a URL's traffic and see something like this, you have an acute problem on your hands.

As you inventory your URLs, you might find yourself horrified to discover occasional flatlines that have lasted indefinitely because you, say, accidentally re-saved it as a draft. Relax, it happens to way more sites than just yours. If you fix the problem, you'll find that your position in search is more durable than you'd think.

Cataloging and explaining all of the ways you can set a URL's traffic on fire is out of scope for this post. But go through your site looking for URLs that have declined very sharply in traffic, figure out why that happened, and fix it.

Bounceback tends to happen quickly.

2. Execute Touch-Up Refreshes

Next up, identify candidates for touch-up refresh. A lot of SEO folks will recommend refreshing content once every six months or when it loses position for its primary keyword. There's nothing wrong with that—it's, in fact, how we used to recommend thinking about refreshes.

But these days we have a finer-turned early detector. We look for a gradual, non-seasonal decline pattern like this one that started in September.

Before a URL starts to meaningfully lose ground on its primary keyword, it suffers gentler attrition on longer tail keywords. Usually when you execute a refresh during this time, it recovers on those longer tails and cements itself for the primary for a while.

The payback tends to come nearly immediately. Here's a graph of the traffic to twelve URLs in a collective state of decline as of June, with a red mark where a mass-refresh took place. The result was a roughly 60% collective traffic increase in the next month.

This is also one of the easiest imaginable interventions. I'm sure every SEO tool on earth has a refresh guide on their site that you can follow and do pretty well. When you're at this light stage of decline, all you really need to do is make sure the text is scannable and the info is current.

3. Execute Comprehensive Refresh

Comprehensive refreshes, on the other hand, are somewhat more involved. You'll need to deploy this tactic for URLs that have declined for a long time and earn almost no traffic. Or you might need to use this tactic for URLs that have never earned traffic but target a high-volume keyword.

And for these, you'll need more elbow grease than just a touch-up. When we do these, we first assess winnability of the keyword and get client input on risk appetite. Assuming we want to take a swing at it, we then use Positional to conduct a gap analysis on the target URL, seeing what it lacks compared to URLs that rank.

Here's a quick glance at what that looks like on our content lab site, where we can see relative word count, questions answered, and more.

In this case, I think the underperformance is down to having a gen-AI app spit out what appears to be some extremely verbose text and simply pasting it as-is. (This was an experiment I ran last year.) But in most cases, you'd likely see an underperformer be light on word count, headers, and searcher questions answered. We'd take this information, turn it into a refresh brief, and execute that brief.

This approach requires enough SEO knowledge to conduct the gap analysis and the subject matter expertise of an author to address the content gaps. You can generally expect traffic recovery in roughly half the time new content takes to rank.

Here's a recent example with traffic to a handful of underperforming URLs in aggregate.

This is a typical graph here. Very low traffic (hence underperformer) with a slight, then large, lift coming in a couple of months.

4. De-Cannibalization

The topic of cannibalization and fixing it really deserves its own post. But to summarize very briefly, cannibalization occurs when you create a number of URLs that all more or less target the same keyword. There are two common scenarios where this happens:

A company spends years journal-blogging about (and indexing) whatever is on their mind that week and then only later decide to try for organic search.
An enterprise outfit creates similar content after acquisitions or content silos with their own separate subdomains.

This also tends to be hard to recognize at the individual-URL-level in a vacuum. If you sell widgets, you'll mainly recognize this by saying, "Wow, we're experts in widgets, but none of our posts about widgets earn any search traffic and we don't rank for 'widgets' anywhere."

This is also not for the faint of heart. You'll likely need to remove or noindex some posts, consolidate others, and treat this as a project. It requires heavy SEO confidence and subject matter expertise, and it takes longer to pay off.

That said, the payoff can be substantial.

With de-cannibalization, however, the significance can extend beyond gross traffic figures. It can result in winning keywords that have bedeviled you for a long time. And that also will probably look like a whole separate category of win to new leadership.

5. New Content

The last piece of this puzzle is, of course, new content. Refreshing content can serve as a powerful booster for your traffic, especially if you don't have much history of doing it previously. But it is ultimately no substitute for new content if you want to grow or even sustain.

Your organic traffic to a URL will decay after 12–18 months, typically at a rate between 1% and 4%. Without intervention, it winds up closer to that 4% figure, but even with intervention, on a long timeline, it still decays. SERPs get more crowded and topical interest declines. (More on traffic declines here, if you're interested).

New content is your antidote to that.

So while you're working hard on the refresh front, make sure you're identifying and targeting winnable keywords with new content. That has the longest payoff period for traffic, typically taking on a hockey-stick shape.

Finding good keywords is generally fairly easy—easier than gap analysis and de-cannibalization. And executing content is fairly easy for an SME. But new content does tend to bog down in planning, ideation, and execution because of its optical importance to most organizations.

Setting Expectations and Looking for Success

To lay out this plan in earnest, look at the traffic patterns for all of your indexed URLs. Then, based on those patterns, put them into the buckets above, if applicable. (Some won't target organic, others will be new or growing, so this only applies to established ones with traffic and underperformers.)

If you then pursue all of these tactics in parallel, you'll realize results that should please the person worried about decline. Your efforts will bear fruit immediately and then also see substantial lifts kick in at a few different points between today and when your new content starts to help.

To really drive this home, however, you need to capture some baselines, so that you can report in the way I have in this post. With the tooling I've built, it's trivial for me, but it probably won't be for you.

Tabulate the traffic data to each bucket of content before and after you execute the tactic. All kinds of wild stuff can impact your site's overall and organic traffic, so you need to capture the before and after of the specific URLs that you're working on. Otherwise, your site's traffic might look flat because all of your organic gains are offset by the decision to start targeting brand keywords with PPC or something.

To put it succinctly, take before photos so that the after photos mean something.

Hopefully you take this plan and recover yourself a lot of traffic. But I also hope that simply having it in your back pocket and presenting it wins you some brownie points and saves you some stress.

The Best Tool for Real Content Attribution? The Fermi Problem

Erik Dietrich — Wed, 07 Aug 2024 15:46:53 +0000

I was recently scrolling through LinkedIn, admiring the art of the single-line hook followed by emoji bullets, when I stumbled on a really interesting question from Fio Dossetto. The question is as follows:

As someone who self-identifies as neither a marketer nor "smarter than" anyone, I figured I'd leave the comments to the thought leaders and call it a day. But I couldn't get the question out of my head, especially since some variant comes up so frequently in discussions with clients.

So in this post, I'll offer the two cents nobody asked for on the subject of challenging content attribution.

Marketers and Measurement: The Quest for Attribution

When I encounter marketers talking about attribution, I generally see an evolution of opinion in two snapshots.

You can't really measure the value that creating high quality content brings. You just have to put it out into the world, do good work, make people happy, and it pays off in the end.

As someone with erstwhile childhood aspirations of being a novelist, I like this take, even if I don't especially agree with it. But it's just a matter of time before some executive pours cold water on it, directly or indirectly, and crushes the marketer's spirit with business-ese.

The marketer's take then evolves to a bit of white whaling.

I know high quality content brings value. Now I just need a tool or methodology that shows that I'm right.

To be clear, I'm not saying that Fio is expressing either of these sentiments -- I don't have enough context to know that. I'm now generalizing my own anecdotal experience to say that content marketers often seem to be on a treasure hunt for validation more than antiseptic measurement. And understandably so, since they're probably responding to an equally unsubstantiated assertion that their work isn't bringing the vaunted ROI to the business.

But the problem with this dynamic, other than the human one of a content creator's broken spirit, is the binary: can't possibly be measured vs. must be precisely measured.

The answer lies somewhere unsatisfyingly in between.

Precision, Measurements, and Decisions

Before getting into the specifics of measurement and approach, I'd like to establish a few business-decision principles.

Measurement only needs as much precision as necessary to make a decision.

You're probably used to waking up and looking at your phone or asking Alexa for the weather. And when you do this, your weather bot of choice conventionally responds with a measurement to the nearest degree. If it didn't and instead said, "it's cold," this would likely annoy you and you'd find a different weather bot.

But do you really need this measurement to the nearest degree?

Or, conversely, do you find yourself upset that it doesn't tell you the temperature to the nearest one hundredth of a degree?

You're probably just asking to try to decide whether to wear shorts or pants. So the only level of precision you actually need, when you ask, might be a personally-tuned device with four readout values: shorts, pants, sweatshirt, coat.

"Alexa, what's the weather?" "Wear jeans today, Erik." "Cool, that works."

Back in the real world, the question that attribution is likely meant to address is "was this video campaign worth the spend?" And measuring the entire odyssey of that single lead is hundredths of a degree instead of "wear jeans."

Decision data only means anything in representative patterns.

For the second principle, I'll meander into a different metaphor. Imagine that your great, great Aunt Bertha passed away, and that you were never aware of her existence until some probate institution mailed you a check for $400.

How should you categorize that income in your budget?

Is it a gift? Is it some kind of negative ledger entry for "taxes" or something like that? Should you create an entirely new category in your budgeting software to tag this with?

The answer is "who cares?"

How likely is this type of event to occur again? You categorize things in a budget so that you can analyze income and spending and make future decisions based on trends. The universe randomly burping a new microwave's worth of money into your checking account is an anomaly worth shrugging and being thankful for your luck. It's not a trend worth analyzing.

I would argue that the same thing is true from a first-hand anecdotal experience of interacting with a brand in a very specific way. Unless there's reason to think that Lavender's video campaign routinely results in internal cross-departmental Slack recommendations, Lavender should just take the W and get on with its life.

Some things are not directly measurable.

And, speaking of someone else's Slack, my last point doesn't require a metaphor. You have to accept that you simply can't measure some things directly.

One of those things is how people at other companies interact in their private collaboration tools. Absent enough money to bribe someone at Slack into sharing it, Lavender would simply have to accept opacity on this front, understanding that there's a black box of a world out there where brand-aware people interact with one another in mysterious ways.

But that's okay. For the rest of the post, I'm going to address how you can reason about these mysterious ways, even if you can't prove them in the most simple, direct sense of the word.

Introducing the Fermi Problem

Let's switch gears now. I just want to see how you think.

How many piano tuners are there in New York? Wait, wait, no, how many golf balls can fit in a 747?

If you've ever heard of a question like this, it's quite likely in the context of a company being cute with its interview process. (Or, more accurately, according to an internal Google study, interviewers making themselves feel smart).

The reason these questions work so well as a vehicle for asymmetrical smugness is that candidates are likely used to a simple relationship between questions and measurements. If you want to know how many golf balls fit in a jet, stuff them in there and count. But that's not the only way to go about answering the question.

These types of questions likely found their way into job interviews because of their Rubix-cube-esque tendency to sample incorrectly for genius. Because, like the Rubix cube, solving the Fermi problem isn't a mark of genius. It's just a skill that any mortal can practice and master.

And that skill is simply one of breaking a complex-seeming problem down into simpler ones that are easy to reason about. How many piano tuners in New York (yikes!) becomes:

How many people are in New York?
What percentage of people own pianos?
How many pianos can the average tuner cover in a service area?

You probably don't know exact answers to those questions, either. But I bet you feel way more equipped to take a guess at each.

Deconstructing the Value Proposition of the Video Campaign

So let's disappoint smug interviewers everywhere and turn Lavender's video campaign into a Fermi problem. The real question, taking some liberties with Fio's original post, is probably "how does Lavender prove the value (likely leads generated) of its LinkedIn video campaign?"

Deconstructing that:

How many people saw the video campaign?
Of the people that saw the campaign, how many of them became durably brand aware?
Of the durably brand aware, how many became (or produced) leads?

Each of these individual components presents its own measuring challenges, of course. But each of these components is also a lot easier to reason about. This helps both with modeling and eventual measurement, or at least approximation, tactics.

Modeling the Video Campaign

First, let's do some modeling. Before even thinking about attribution, which is really a lagging indicator of campaign success, we should have a decent working hypothesis that this campaign will pay off.

Something I've probably bored most of our clients with is an exercise where we document assumptions as variables. If you've followed this blog long enough, I've also bored you with it in the past. This is crucial because it lets you move forward with imperfect precision.

For instance, I don't know what kind of qualification rate Lavender had from impressions to durably brand aware, nor do I know how many durably brand aware people become leads. So I guess. Let's say, I dunno, 1% and 2% respectively.

I also don't know what video campaigns go for on LinkedIn, but I can do one better than guessing. I'll have ChatGPT make something up.

Alright, works for me. And that's all we need to get started. Here's an initial model.

(I didn't model in video production costs because I don't want to get too in the weeds.)

Anything in purple is an assumption. Anything in that other, different purple is a measurement (I'm no graphic designer, sue me). We don't have any of those yet, but we can later.

Tuning And Using the Model

Let's revisit the earlier Fermi deconstruction.

How many people saw the video campaign?
Of the people that saw the campaign, how many of them became durably brand aware?
Of the durably brand aware, how many became (or produced) leads?

What I've done here is to hypothesize reasonable answers to these questions, using a combination of LLM wisdom and simply making things up, which I'm pretty sure is how 95% of business is conducted these days anyway. I'm being snarky and self-deprecating here to drive home the point that a guess based on any kind of field experience is actually a pretty good seed for this type of model.

The next thing I would do is bring this to people with relevant experience for a discussion to poke holes in my uninformed assumptions. I've done a lot of ROI math on marketing campaigns, but someone more experienced in this particular medium than me might have past data on the subject. They might say, "ChatGPT is totally wrong -- it's way more than that for CPM -- but you can also expect way more than 1% of people to become brand aware."

Perfect, thanks! I want someone like that to poke holes in my assumption to drive to a better hypothesis.

Now, no matter how savvy someone's educated guesses are, they're of course still guesses. But this back-of-the-napkin exercise can help with very broad strokes evaluation of a campaign.

If, for instance, leads are only worth $50 to Lavender, given the relatively light figure I made up for LTV, then this might not be the campaign for them. If, on the other hand, leads are worth $5K, then we should stop futzing with a spreadsheet and start making videos yesterday.

Turning Hypothesis Into Approximation and Measurement

Having formed a reasonable ROI hypothesis via modeling, let's assume we now unleash this campaign on the world and prepare to bask in the pipeline. As we do that, we can right out of the gate turn impressions and ad spend into measurements in the model. Those are easy and precise figures.

Where things get trickier is reasoning about "durably brand aware" and "qualified leads" from the campaign.

You really can't measure the number of impressions that turn into durably brand aware people. But you can ask yourself whether your initial assumption and model continues to seem reasonable.

To understand what I mean, ask yourself what you might expect to happen if you relatively quickly generated 5,000 durably brand aware people.

You'd probably gain followers on LinkedIn itself and at a faster clip than historically.
Branded searches would likely increase.
Your YouTube channel would likely see new followers, and at a faster rate than it had accumulated them before.

And those are all things you can directly measure. Attributing them to the campaign is a challenge, sure. But if your channel followers increase at twice the pace that you used to pick them up, I'd say it's quite reasonable to chalk the surplus up to the campaign for evaluation purposes.

You can do similar brainstorming around qualifying leads.

Evaluating the Campaign As You Go

I want to close this out by fundamentally reframing the idea of attribution. Or at least reframing the question that you're trying to answer.

It's tempting to try to answer the question, "how many (and which) leads can I attribute to this campaign?" And if you have the killer toolset that can actually, precisely answer this, then I envy you. But a more realistic question to answer on an ongoing basis is this:

How wrong would our model need to be for us to pull the plug, and is there any reason to suspect we're that wrong?

Attribution tooling can help you measure some things, and it can reduce the uncertainty surrounding others. But it can't get you all the way there, into people's Slacks, across their browsers, over the river and through the woods. And it can't tell you when you've run the campaign long enough to have sufficient data or leading indicators of success.

To evaluate campaigns, you're going to need to look away from precision and into the realm of uncertainty and probabilities. That might seem daunting. But the good news is that the skill of solving Fermi problems is tool-agnostic.

And beyond that, it shifts the burden of proof for content folks. You can flip "prove this works" around with "here's my model, you prove it doesn't."

And either way the business wins. Either a successful campaign keeps going if they can't prove it, or you improve the model and fix (or stop) the campaign, if they can.

The Flat Squirrel Barrier to Content at Scale

Erik Dietrich — Tue, 23 Jul 2024 12:54:55 +0000

Be decisive. The road of life is paved with flat squirrels who couldn't make a decision.

I don't know who originally said this, so I can't properly attribute it. I guess that makes it some kind of piece of folk wisdom, now best suited for cheugy merchandise.

But whoever dreamed it up has a gift for impactful figurative language. I'm sure you can picture the situation -- your car barreling down on some hapless squirrel who starts left, then right, then backward, then splat. Had the squirrel run in any direction, it would have met a better fate than it did by fretting to literal death about the decision while doing nothing.

I'm setting the stage with this gruesome metaphor to make my point here memorable. And my point here is that collective flat squirrel syndrome is going to be your organization's single biggest barrier to content and funnel metrics at scale. (And I should note this only applies to customer acquisition strategies that require and substantially economize on scale: SEO, communities, parasocial followings, podcasts, etc.)

Here are some things you might think would be the problem but aren't:

It's so hard to find good writers.
The keywords in our space are super competitive.
{Insert our audience here} is such a picky audience.
There just aren't any public distribution channels where our audience hangs out.
So few people know how to talk shop to our audience.

Nope, nope, nope, nope, and...drumroll, please...nope.

Those problems are all actually relatively easy to solve compared to flat squirrel syndrome. The reason for that gets a bit into org theory but suffice it to say that this problem is intractable because it's human nature and because the solution has to come from within, unlike all of the logistical issues above that can be solved with staffing and experimentation.

The Content Manager Case Study

To make this less abstract, I'll describe a situation I've observed so often over the last seven years that I would definitely call it an anti-pattern.

Some A-round tech company with a first marketing hire is putting out content at a decent clip through a combination of freelance labor, internal collateral curation, and pure grit. It's not perfect, but it's moving funnel metrics up and to the right.

As the engine and labor pool grow, the company hires a content manager -- probably a historical individual contributor with a journalistic or comms background of some kind. That person comes in and pumps the brakes on content.

Whoa, whoa, whoa, this is all wrong, and our audience thinks we're amateurs. We can't keep putting out content until we straighten out our position on Oxford commas and get things up to snuff.

The longer the site goes without new content, the higher the stakes become. Which topics show our brand in the best light, and which distribution channels will garner the most halo effect and chance for the good kind of virality? Are we mentioning AI enough? We really need to nail this, so let's --

BAM!

Flat squirrel. It's been nine months with a grand total of two blog posts, and the content manager's Linked In profile is suddenly sporting the "Open to Work" banner and a message about how they loved their time at [A-round], but they're looking for their next challenge.

Flat Squirrels and Catastrophic Opportunity Cost

A firing like this is a genuine (and avoidable; more on this later) human tragedy, but it's also one that begets an organizational tragedy. For the individual, the stakes are a job search, but for the organization, the stakes are jaw-dropping sums of eventual unrealized revenue.

From a business perspective, any scaled-based content marketing channel (SEO, YouTube, audience-building, etc.) has a payback-value curve similar to one of compounding interest for retirement savings. In other words, a soon-to-be-flat squirrel dithering in the early going is like a 25-year-old dithering about retirement savings.

I'm too stressed out right now to opt into the 401k, so I'll wait till next year.

Poof. 50K gone from eventual retirement portfolio.

I don't want to invest in the wrong stocks, so I'll keep putting this off until I can take an investing course.

Poof. 150K gone from eventual retirement portfolio.

A shrewd executive recognizes this parallel, and so content-based flat-squirrelling doesn't appear to them as "we failed to publish a blog post yet again," but rather as "we just lost 200 more leads over the next two years through simple indecision."

The problem horizon of the flat squirrel for the organization isn't so much traffic or subscribers moving down and to the right at the moment. It's how much longer it will take to get into the fun part of the hockey stick than if they had just kept the trains running.

Significant Chokepoints of Indecision and How to Address Them

While I imagine that a significantly frenzied squirrel could find any point in the process to panic, there are generally two major chokepoints in content programs for this kind of thing. I'll address each in turn.

Indecision in Ideation

The first major bottleneck tends to occur during ideation. This could be thematic ideation for campaigns or even channels themselves. But the more problematic form of it tends to happen at the component level: blog post, video, podcast episode.

Basically, "What should we talk about this week?"

If you haven't started on the campaign yet, you might face organizational blank page syndrome, or you might have nerves resulting from spotlight effect. "These first few need to be bangers."

Or perhaps you're in the thick of things, and the daunting prospect of having micro-strategy sessions each and every week encourages procrastination. Cadence slips because thinking of a unicorn idea that is thought-leader-y and SEO-y and mentions your product, and goes viral and gives the C-suite warm fuzzies when they read it is understandably daunting.

So eventually content shrivels to changelog posts and the occasional PR piece.

Fixing Indecision in Ideation

First, and I can't stress this enough, do not make decisions episodically and one-by-one. That. Is. Exhausting. (And a recipe for cannibalization and redundancy.)

Decide upfront on campaigns and make idea acceptance criteria a feature of them. "If it's about MySQL at an advanced level, we'll ship it" or "if it's a question from a customer, we'll record a YouTube video to answer it." By doing that, you've neatly pre-made decisions and removed in-situ judgement from the equation.

Secondly, boot some cooks out of the kitchen. As a lifelong cynic, I've always enjoyed despair.com for its witticism, such as

Meetings: none of us is as dumb as all of us.

While that is, of course, nakedly cynical, there is a grain of truth to it in the sense that additional stakeholders can create diminishing and even negative returns, especially when decisiveness is important. And if you have six people that all need to agree on topics for your blog, I'll save you the suspense: you're not going to have a blog.

Make one person the primary on ideation and trust that person. Let them solicit feedback as needed but grant them autonomy.

Indecision in Review

The next major source of indecision will come in the substance of the content itself or, more specifically, in the review of that content, as opposed to the collaboration.

There are two sub-forms of this. One involves post-creation review collaboration, and the other is more about incorporating feedback into future content.

The first form tends to involve having multiple gatekeeper-style reviewers of content. Someone writes it, then a copyeditor reviews it, a product marketer asks for more incorporation of the market position, a PR person takes a whack at it, and maybe a founder even wanders by for good measure.

I've written in the past about how multiple reviewers absolutely torpedo your cadence. But beyond this, you'll inspire a kind of non-productive learned helplessness in those tasked with producing the content. Your staff writer, for instance, might start phoning it in with ChatGPT content since six other people are going to turn it into a frankenpost anyway.

The second variant is a little better for cadence in that you publish before gathering a lot of "next time could you" type feedback. But it still creates the dynamic of confusing, often-conflicting guidance that depresses the cadence of content creation.

The common thread in both of these situations is collective, fear-based indecision. Generally, the editors, product marketers, SME reviewers, PR people, executives, etc. aren't weighing in from an angle of "I'm excited to mention X" but rather "I'm afraid that X will happen if we publish this as is, so let's hold off, discuss, and revise."

And hold off you will. Until, well, you know. Bam.

Fixing Indecision in Review

Fretting over draft content tends to be harder to overcome than fretting over ideas. After all, you don't publish ideas, nor do you have the ability to tangibly imagine someone reading (and reacting poorly to) an idea.

That said, the same tactics apply to fixing this as to fixing ideation. Shoo as many of the cooks out of the kitchen as you can. This will serve both to make creating the content less soul-crushing and also to reduce time to publish by simple virtue of less calendar time to solicit all of those reviews.

Also, establish acceptance and rejection criteria for content, rather than having a subjective review pass. In other words, if the criterion for publication is "Gatekeeper Greg must say it's good," then you're only going to publish as quickly as Greg can read it and decide he likes it. If you have clearly defined criteria for acceptance, you can round-robin the review process for efficiency, and you have pre-canned evaluation criteria for "is this good" that don't require subjective, ad hoc decisions in the moment.

One final way to steel yourself against delay-causing indecision about content is to make peace with the fact that, no matter what you publish, someone will think you're an idiot. The internet can't collectively agree that the earth is round. So no matter how correct, fact-checked, grammatically perfect, and Shakespeare-esque your prose, if enough people read it, someone will roast you on Twitter saying, "your wrong and dumb and your grammer is wrong and i hate you"

Once you accept the inevitability of negative feedback, it's easier to stop fretting about it and get down to business.

The Content Manager, Revisited

I want to conclude this post by circling back to the fired content manager. I called that a tragedy, and I genuinely mean that. Because most likely, the faceplant the content manager authored was ultimately leadership's fault.

I say this because they most likely told the content manager upon hiring, "you need to produce high quality content that earns traffic." And when you hire a technician and cast that person as a subjective expert in charge of adjudicating quality of craft, they will dive into the craft weeds (Oxford commas) rather than the comparably inscrutable business weeds (traffic, pipeline, and CAC).

You will then probably worsen this problem if, early in the content manager's tenure, an executive reads them the riot act for some "bad" piece of content they wrote or commissioned. Lesson learned. Produce less content, agonize over it more, and make sure it's "high quality" for some definition of "quality" that nobody has established.

When consulting on content programs, I often say something that people mistake for a joke. "If your main goal is subjective quality to avoid criticism, the easiest way to achieve that goal is to produce as little content as you can." That's not a joke -- not producing content is literally the most cost-effective way to achieve criticism avoidance.

Establish Clear Goals, KPIs, Countervailing Concerns

At this point, people I'm talking to will say, "okay, okay, smartass, obviously that's not what we mean." But I spent a bunch of years as a management consultant and I can tell you from extensive experience that people will achieve the goals (explicit or implicit) you set for them even it means burning your company to the ground to do so. You don't get to say "but that's not what I meant!" after creating a perverse incentive for them.

Therefore, achieving volume funnel goals means being very clear about primary goals and countervailing goals. You have to establish that the true north goal is, say, qualified leads and that KPIs for qualified leads are things like (in reverse order) site traffic, rankings, followers, content produced, and content scheduled.

Then you establish that quality is a countervailing concern, meaning the charter becomes "produce the true north goal of funnel metrics, mustering as much 'quality' as you can." (It also doesn't hurt if you de-subjectify "quality" with things like acceptance criteria and style guides.) This makes it clear to them how to resolve two simultaneous and potentially conflicting charters you've handed them.

The only last thing you might find yourself wondering is "what if I want quality as the primary goal and funnel metrics as the countervailing concern?" And to that I say "then forget any volume acquisition strategy involving funnel metrics, because you're going to fail."

That, also, is probably a story for another post. But coming full circle, giving up on volume now and pursuing a different set of tactics is better than standing in the road, trying to do both, until BAM. So flip a coin, pick one true north or the other, and get moving. Either direction is better than 3,500 pounds of car rolling over you.

Where Did My Traffic Go? Hint: It Wasn't an Algorithm Update

Erik Dietrich — Wed, 10 Apr 2024 13:29:55 +0000

If you were to take a stroll through Hit Subscribe's offering page, you'd see that we now have a first-class "traffic recovery" offering. We added this because of the frequency with which we field the question, "Why is my [usually organic] traffic declining?!"

In fact, we field that question so frequently that I'm writing this blog post to distribute to friends and prospects to help with self-diagnosis, potentially saving you some money on a possible engagement. So if that's what brought you here, sorry about your traffic. But don't worry. We'll get it sorted.

In this post, I'll discuss the most common reasons we see for lost traffic, describe the decline pattern you would expect to see if these things were happening, and explain how to start remediating the issue.

First Things First: Forget About "The Algorithm"

One of my all-time favorite books is Joseph Heller's Catch 22, wherein he amuses the reader with assorted, specific paradoxes. The military grounds "crazy" fighter pilots and allows sane ones to fly, and they evaluate craziness by whether or not the pilot wants to fly. Anyone who doesn't want to risk their life flying is non-crazy, and therefore must fly.

Of course, paradox exists beyond the novel. Probably preceding it and in a nod to the importance of status illegibility, Groucho Marx once quipped, "I refuse to join any club that would have me as a member."

I'll offer one another paradox for your consideration:

"The algorithm" only punishes those who go out of their way to avoid punishment.

In less quippy terms, if you've been generating content in good faith without thinking about "the algorithm," you're safe. Hit Subscribe, for instance, has managed analytics for more companies than I can count at this point. And we have never seen an algorithm update have any impact on anyone. We honestly don't even pay attention to them.

Scumbag and Non-Scumbag SEO

I personally divide the SEO world into two camps: scumbag SEO and non-scumbag SEO. Our non-scumbag SEO methodology consists primarily of two steps:

Figure out what questions people are asking the search engine and answer those questions.
Do it on a site that doesn’t suck to visit.

Luckily, if you've been creating content in good faith and earning search traffic, you have, yourself, been executing this process. This is, almost without exception, the case for everyone that asks about traffic declines.

Scumbag SEO, on the other hand, adds various additional steps to the process:

Spam comment sections with nonsense that talks about your site.
Stuff keywords into your prose until your reader thinks they're having a stroke.
Pay an "SEO firm" $5 per hour to do things you'd prefer not to know about.
Hack into abandoned WordPress sites and add links to your domain.
Conduct "SEO heists" using generative AI.

Scumbag SEO is a constant game of taking cost shortcuts and avoiding punishment, always staying one jump ahead of the breadline. And scumbag SEOs are who Google punishes with its algorithm updates.

If you're doing scumbag SEO, trust me, you know it, and you know the risks. You don't do that kind of thing by accident.

(As an aside, a lot of SEO conusltants will likely take issue with what I'm saying here. But they do so from a position of extreme motivated reasoning. Their livelihood depends on you believing the only way to avoid Google's wrath is to pay an SEO consultant to execute an endless punch list of billable minutiae.)

So if it wasn't the algorithm, where did your traffic go? Let's take a look.

The Non-Issues

Here's a quick caveat about the rest of this post before proceeding. When I talk about what the decline will commonly look like, I mean just that: commonly. There can always be edge cases that don't follow the pattern.

With that lawyer-speak in the books, let's talk traffic declining. Before looking at legitimate sources of traffic decline, let's look at some things we see that aren't actually problems.

1. Your Analytics Tool Is Broken

It might surprise you to learn how often the "problem" isn't with the site or rankings but with the analytics tool itself. I've lost track of how many times over the years someone has, in a panic, asked why their traffic is all gone, only to experience great relief upon learning, no, it's still there. Google Analytics (or whatever) is just broken, so you're flying blind.

Lest you feel bad, here's a screenshot of Hit Subscribe's GA4 traffic over the last 12 months.

We don't depend on the website as a source of lead generation, so we don't pay a lot of attention to hitsubscribe.com's analytics. If you doubt that, check out this two-ish month window where we "had zero traffic."

Now, imagine the problem wasn't yet fixed and we first noticed this flatline trend back in September. You could understand someone panicking a little.

But ask yourself if it seems likely that a normally functioning website would suddenly drop to zero traffic. I mean, I had personally visited the site, so it couldn't actually be zero. So if you see something like this, take a breath, since the most likely situation is that you need to fix your analytics setup and your traffic will "come back."

What You'd Commonly See: A sudden total, or near-total drop in traffic that stays at or around zero.

What To Do: Talk to whoever administers it about reconnecting your analytics tool.

2. Normal Seasonality

Next up in the non-issue category is seasonality. This is any traffic dip that you could expect because of what's going on in the world.

For instance, in B2B settings, people tend to do fewer business-y things (such as visiting your website) at certain times of year: holidays, back to school, summer vacations, etc. All of those things can have an impact.

Take a look at this anonymized organic traffic graph, for instance, noting the dates.

What do you suppose happened there? A catastrophic traffic fall-off? Or, "Hey, it's the week between Christmas and New Year, and very few people are doing business things."

Christmas is an easy one, but seasonality occurs in all sorts of patterns (including the troughs above and in almost every B2B organic graph that represent weekends). So one of the first things that you should check when you notice a traffic drop is whether it might be attributable to world events.

What You'd Commonly See: A dip in traffic that followed a repeatable pattern.

What To Do: Form a hypothesis about seasonality, and then check to see whether you've lost traffic in this fashion in the past.

3. Sometimes It Be Like That

The last thing that I'll mention is that traffic to your site is more of a game of aggregates and patterns than a precise daily march upwards in volume. In other words, you might have 600 visitors on Monday, only 500 on Tuesday, and 600 again on Wednesday for reasons that you'll never discover.

When you're looking at a channel with significant traffic, you have to take care not to focus too narrowly and thus detect phantom trends. If you fall into this trap, then you'd panic every Saturday about the graph in the last section.

Generally, we advise clients to look at a channel's monthly production, which tends to provide enough data points to smooth out inexplicable anomalies and the vagaries of life. And even at the month level, occasionally you'll see a temporary dip in an otherwise upward trendline. And you'll probably never discover why, exactly.

What You'd Commonly See: A dip in traffic too new to have statistical significance.

What To Do: Chart out the trendline of traffic over the past few months and keep your eye on it for a few weeks to ensure it reverts to the mean.

Normal Wear and Tear

Alright. With the low-effort stuff out of the way, let's move on to actual, meaningful traffic declines and what to do about them.

I'm calling this next category "normal wear and tear" because it's what happens naturally, when you're not doing anything "wrong" (by which I mean something that would materially impact your standing with Google and the search experience). To understand this, you need to axiomatically accept that when you do nothing to your site, your traffic will naturally decay over time. You can read more about that here, if you don't want to just take my word for it.

4. Gradual Traffic Decay

Here's a screenshot of Ahrefs' approximation of organic traffic to a site. This site published organic-traffic-targeting content from 2017 until the middle of 2019 and then stopped. And this graph is a textbook example of what you should expect in that situation.

Any organic content that you publish will have a lead time before it starts to earn traffic. As a result, sites exhibit a seemingly curious property once you turn off the content faucet: they continue to grow for a while. (This often creates the illusion among site owners that organic traffic is more durable than it is.)

In the graph above, the site did indeed continue to grow for a while before eventually plateauing at the beginning of 2021 and starting a gradual decline. At least, that's what it looks like in aggregate. In reality, decay for a given article starts 12 to 18 months after publication, and what actually happened at the plateau was that the site hit a tipping point where the decay of early articles caught up to the growth of more recent ones.

Usually when people ask me about their traffic and this is the situation, they're asking when they're in a steady state of decline (e.g., they'd ask at the beginning of 2022 in this graph). So they stopped producing much content a while ago, observed a plateau and decline, but hoped the traffic would "come back" after a while.

It's not coming back, my friend. You're going to have to reinvest in the channel if you want to regain your traffic.

What You'd Commonly See: A gradual decline in the low single-digit percents (assuming little to no new content).

What To Do: Start executing new content, or at least refreshing existing content.

5. Top-Heavy Traffic Decay

For this traffic decline, the same mechanics as the last one are at play, except that the nature of the traffic is a little different. In the graph above, the site had dozens of articles, the overwhelming majority of which were producing a decent amount of traffic. This is the healthy, expected situation if you're intentionally targeting organic as a traffic or lead gen channel.

But there's another common situation among site owners, particularly those who have stumbled into organic traffic rather than intentionally seeking it. This is usually among the set of people that journal-blog and engage in audience building (e.g., my consulting site, DaedTech). And the situation is that, out of say, 100 articles, three articles will account for 95% of their organic traffic.

When this is the case, those articles are still subject to the vagaries of traffic decay. But that decay tends to look much "lumpier" and sudden. If a single article is bringing half of the traffic to a site and that article declines in rankings, you might lose a quarter of your site traffic in a week.

Luckily, this is pretty easy to diagnose, since you can simply look at the traffic individually to the traffic earners and see where the bleeding is happening.

What You'd Commonly See: A sharper decline and plateau in traffic.

What To Do: Refresh the articles in the short term and try to make the channel less top heavy in the longer term.

6. Topical Interest Decline

This last one under natural wear and tear is probably the biggest bummer for any site owner. In your analytics dashboard, it will look much like the gradual traffic decay pattern, if a little sharper in downward slope. But it has much different implications.

This occurs when the broader internet is losing interest in what you've been posting about.

With normal traffic decay, you tend to lose traffic to other content creators targeting similar searches and competing with you for their visits. Topical interest remains strong, but you have more trouble reaching them unless you update your content. But with interest decline, the searchers themselves go away.

For instance, let's say you'd created a site dedicated to the erstwhile social media platform Google Plus. You'd have seen a gradual traffic decline over time without new content, but you'd even see it if you were producing new content. People stop googling and reading about the term, so the traffic simply isn't there.

What You'd Commonly See: A gradual decline in the low single-digit percents, new content or not.

What To Do: You probably have bigger problems than generating traffic.

Technical and Site Issues

For this last set, I'll cover some common scenarios where there's some active, likely inadvertent self-sabotage happening. Please bear in mind this is not, and is not intended to be, an exhaustive list—just some common ones that we see.

If, for instance, you queued up some scumbag SEO and made Google legitimately unhappy with your site, you would also lose traffic. But I'm not covering that here, under the fundamental premise of the post (that you've been acting in good faith).

7. You Unpublished Some Content

Don't laugh. Accidentally unpublishing content happens way more frequently than you'd think.

For instance, about a month ago, I deleted an inactive user from our CMS. It turned out, for reasons that cost a web dev agency any future business of mine, that this user was inexplicably the author of all of our landing pages except the blog. So, before we reverted it to a valid state, our site briefly had nothing on it except the blog.

Now we obviously noticed this relatively quickly. But we probably wouldn't have, had this user only had the byline on a few two-year-old blog posts. In that scenario, we'd simply have lost some traffic to formerly valid URLs now throwing 404s.

If this happens, you'll generally see a sharp but noncatastrophic dip in traffic. So one of the first things I'd do is look for missing articles. (Explaining how to do this is a topic for another day—let me know if you're interested.)

What You'd Commonly See: A sharp, noncatastrophic decline and then plateau.

What To Do: Republish the content and request indexing.

8. A Recent Migration or Site Redesign Created Technical SEO Problems

By far the most frequent and tragic loss of traffic that we see arises from some kind of site overhaul or migration. I'm not exaggerating when I'd ballpark that our clients have collectively lost tens of millions of visitors over the last seven years to this.

There are far too many things that can go wrong for me to enumerate them here. But they tend to revolve broadly around content migration, site performance, improper setup of SEO artifacts (sitemaps, robots.txt, etc.), and improper redirection of content.

Luckily, this is extremely easy to diagnose, at least at the holistic level. You're obviously going to know if you recently executed a site overhaul or domain name change.

Fixing it, however, can really run the gamut in terms of effort and complexity.

What You'd Commonly See: A sharp decline and then variability or fluctuation.

What To Do: If you don't know where to start, ask folks in your network for advice or a referral. Don't DIY this.

9. Something Acute Is Wrong With Your Site

In a way, this next situation is a generalized version of the last one. If there is something substantially wrong with your site, recent overhaul or not, it can catastrophically impact your traffic.

Like the last situation, this can really run the gamut: hosting issues, site security issues, server errors, a CMS bug, and many reasons beyond that. But the common thread is that something pretty major is going on with your site.

A lot of times this will cause problems beyond a drop in traffic, but not necessarily. Or it might just be that nobody is reporting those problems to you. Either way, if you see a large, sudden drop in traffic and it's not a faulty analytics setup and you haven't recently redone the site, the first thing to do is start troubleshooting for site problems.

What You'd Commonly See: A catastrophic decline and then plateau.

What To Do: Navigate to the site yourself and start at least doing some manual QA to see if there's anything obviously wrong.

10. Something Subtle Is Wrong With Your Site

This last traffic loss scenario is probably the most bedeviling for all parties involved. If there's something catastrophically wrong with your site, that's awful, but at least it's obvious what's wrong and it's all hands on deck to fix. But what about when there's something seemingly subtle or unnoticeable tanking your traffic, like some kind of digital planet X?

Examples of this that we see include CMS SEO misconfiguration, slow page loading, bad user experience, searcher-unfriendly page layouts, and other similar arcana (for most). In these situations, sites still earn traffic and it can be extremely hard to know if anything is wrong, let alone what.

There's a decent chance that someone with these problems would never notice them. After all, they might experience steady traffic growth, in spite of chronically underperforming where they should rank. Or if the subtle issue cropped up more recently, it might take the form of gradual stagnation or decline, followed by underwhelming growth.

We have a methodology for this that would be hard to DIY. It involves assessing how an article should perform and then looking for systemic underperformance.

Without that, DIYers generally need to rely on (noisy) SEO tools for site audits. That can be a frustrating path, but it's a decent starting point at least, if you think your site is underperforming.

What You'd Commonly See: A medium to gradual decline and then plateau or underwhelming growth.

What To Do: Use one or more SEO tools to audit your site, start addressing issues, and see if things improve.

Troubleshooting Traffic Drops, Philosophically

I've laid out a laundry list of common situations that we see, how to recognize them, and what to do next. But I'd like to close with a bit of advice that applies to any and all situations, even ones not covered here.

Deconstruct the problem.

Traffic to your site doesn't come holistically. It comes via individual URLs.

So start by breaking down the traffic to each individual URL. This will allow you to isolate the source of decline, which will in turn make for easier troubleshooting.

Did all of the decline come from one URL? Probably something wrong with that URL.

Did all of the decline come from pages tagged as glossary? Probably something wrong with the glossary.

Has just about every page on your site seen a decline? Probably something systemic.

When the problem space seems overwhelming, it's tempting to attribute your fate to some capricious, angry search god punishing you for your content sins. And then it's tempting to just give up.

But once you start to break it down, you'll almost always find that the problem is much more mundane...and much more fixable. And then you'll have your traffic back before you know it.

Getting Above the Brief: How to Improve Your Developer Marketing Positioning

Erik Dietrich — Fri, 15 Mar 2024 14:50:19 +0000

Recently, I wrote a post about changing Hit Subscribe's positioning, which I intend to distribute to clients and prospects in appropriate situations. I shared it to DaedTech as well, assuming that an audience of (I think, still) largely engineers might find the positioning insight interesting.

What I didn't expect was the traction among developer marketing folks, including a bunch of people reaching out to me for direct discussion. But since that's what happened, I reread that post through the eyes of a developer marketer. And doing that, I realized my explanation of why developer marketing made for terrible positioning was unsatisfyingly hand-wavy:

It’s terrible positioning because it’s all about the labor and not at all about the client, what they’re looking for, and what kind of transformation they’re hoping to achieve.

That's true. But there's not a lot of meat on the bone if you're a developer-marketing freelancer or small shop.

So, even though it has little relevance for either Hit Subscribe's prospects or my historical engineer audience, I'm going to unpack this a little more. I've spent almost fifteen years blogging about whatever is on my mind, so why stop now?

Let's look at the positioning problem with "developer marketing" in detail.

What Makes Developer Marketing Different?

"Developer" is, broadly speaking, a job title. This makes "{job} marketing" the abstract base class of "developer marketing."

So the question becomes this: what makes developer marketing different from, say, lawyer marketing or shift-supervisor marketing or just plain marketing? What, specifically, does it involve and what makes it distinct?

I googled "developer marketing" and here's what I found people saying it involved:

A near-universal agreement that "developers hate (traditional) marketing." (I don't agree with this, BTW.)
An understanding of how to leverage Stack Exchange sites and GitHub.
A knowledge of the "fragmented" communities in which software developers hang out.
A knowledge of social media on which developers hang out.
"Authentic" and "deeply technical" content with code samples and demonstrations.
Being a software developer or just deeply understanding one, depending on whether the agency targeting the keyword "developer marketing" was practitioner-led or not.
Creation of content that shows (not tells) a developer tool's value to the prospective audience.

I could go on, but I think this covers most of it. And piling on to what you already know isn't germane to my point.

Below the Brief: All of Developer Marketing in Three Tragically Tactical Concerns

What is germane to my point is what this all actually reduces to, in the grand scheme of things. Everything that makes developer marketing different from other flavors of "{job} marketing" folds into these three concerns:

Who should write the content?
What should the content include?
Where should you distribute this content?

(I'm omitting the reader persona as a fourth concern, since the marketing group doesn't strictly control that. They control the three above and hope the persona reads, if they've done it right.)

For context, here's a modified and highlighted screenshot of one of our brief templates:

Everything about developer marketing sits "below the brief." To clarify what you may have already inferred, I'm distinguishing "above the brief" from "below the brief" as a sort of Mason-Dixon line of strategy and tactics.

Above the brief, you have marketing and business strategy. Taking into account the business's value prop, GTM motion, and budget, among other things, the marketing group forms a strategy, which consists of marketing channels. Within those channels, they launch campaigns as tactics. And when those campaigns involve content, they have briefs as the most tactical thing with any strategic component to it whatsoever.

That's above the brief, and it doesn't concern developer marketing. Below the brief you sit, dear developer marketer, crafting code samples for posts and knowing how to share things to r/programming in a community-friendly way...assuming the brief calls for you to do so, that is.

The World Below the Brief

At this point I want to call something out, lest you think I'm needlessly dismissive. Tradecraft at the individual contributor level is both valuable and a hard-won skill. As someone who has been doing both for decades, I can tell you that content writing and programming are anything but easy, so you should be proud if you've become proficient or mastered either, let alone both.

But none of that makes these skills strategic, from an organization's perspective.

However well you know GitHub, whatever your Stack Overflow score is, or however many content marketing badges you have, it's all tactical. It's all below the brief. In this sense, developer marketing is like "Chicago-style-guide marketing," where you write blog posts in that style, or "markdown marketing," where you write blog posts in markdown. It's all so tactical that it doesn't bear mentioning during strategy meetings.

Incidentally, it's also table stakes for a job description. In other words, nobody writes a brief that calls for an author who doesn't know what they're talking about or an editor who doesn't know the style guide or collaborators who can't use the drafting tool. Rather, the person writing the briefs is specifically looking for staff proficient in these skills as a simple requirement.

Up Periscope: Peeking Above the Brief

This is rock bottom, in terms of what I'm asking you to accept. I want you think of "developer marketing" as positioning sharing the same fatal flaw with "Chicago-style-guide marketing" and "I-write-in-markdown marketing."

If you can do that, even as an exercise, I think it'll become easier for you to recalibrate and move towards more productive positioning for your practice or business. And that's what I'm going to discuss for the rest of this post.

I want you to stop positioning yourself as competent at table-stakes tactics. I want you to stop boring your economic buyer with your commodified tradecraft. I want you to get above the brief.

The first step is a small and subtle one. Understand that you, as a developer marketer, aren't selling content. You're selling staff augmentation.

Specifically, you're selling an answer to the question, "Who will execute this brief within the allowed budget?"

Remember, tradecraft (using code samples, writing "good quality content," etc.) isn't strategic. But staffing and budget are, even if you're currently interacting with them two levels below where the players sit. So start by understanding that your current positioning solves a staffing and recruitment problem.

Next Step: Lose "Developer" from Developer Marketing

The problem is that selling staff augmentation is also highly commodified and thus fairly prescripted with positioning. Staff augmentation (and thus developer marketing) agency positioning is iron triangle stuff:

Fast, cheap, good. Pick any two.

Generally the upward pressure of software skills on your cost of goods sold (COGS) will cause you to land on "fast-good." This is likely why all developer marketing services wind up marketing themselves with how "technically deep" the content is and how you can get it to the buyer when other people struggle to do it. You're justifying the higher cost of staffing with engineers than with, say, general comms folks.

So how do you escape the iron triangle and being a staff augmentation service? How do you blast into a third dimension and look down ruefully on your erstwhile competitors lying flat inside the triangle?

Lose "developer" from describing what you do.

You do marketing. Or, probably, content marketing, since that seems mostly what folks mean by developer marketing.

It's All the Same Stuff

Let me explain this bit with an example. I've only recently articulated positioning for Hit Subscribe, mainly because I've only recently bothered to give specific positioning any thought. But I understood the inherent flimsiness of "developer marketing" years ago.

I say this because just before the pandemic, in early 2020, we started to work outside of developer tools. Even back then we'd been delivering traffic hockey sticks through keyword research long enough that clients came to us for SEO expertise. And when our contacts at some of those companies started to leave and take different, non-dev-tools jobs, they asked to bring us with.

Can't you just do for my new company what you did for us before?

After a little hesitation, my response was, "Huh, now that you mention it..."

Modulo the author backgrounds, building from zero to significant organic traffic was the same. So back in early 2020, we found ourselves asking whether we should set up "Hit Subscribe Transportation & Logistics" and "Hit Subscribe Legal Tech" as divisions or possibly franchises.

(We did briefly start to have divisions but have since concluded that it's not worth trying to maintain specialized benches in other disciplines.)

Discovery and Removing the Wrong Focus

The important thing to understand here is that all of the developer marketing concerns were tactical and fungible in the face of a business goal: open up organic as a channel, fast. It was with this realization and against this backdrop that I put on my management consultant hat and started to do a long, casual process of discovery. Instead of hawking content at the blog post store, I started to learn a lot about marketing strategy by talking to and collaborating with founders and execs.

(It obviously didn't hurt here that I had a lot of prior career experience as an exec and working with execs.)

When you remove the word "developer" from what you do, it forces you to stop wallowing below the brief. You have to start looking at your clients and their desired outcomes to reorient yourself.

Okay, clients turn to you to staff their briefs, but why? Why not staff in another way or just forgo the channel altogether since it's expensive and challenging? Why not just run ads?

You can conduct discovery over time to learn these things. Or, absent that, you can study your book of business for common themes. What common themes (other than markdown to write blog posts and code samples in them) do your clients share?

How do the content campaigns you staff help those businesses? What do they do to help the marketing group? How do they help your main contact earn a promotion?

Positioning Is a Journey

I won't pretend that this market research and discovery is easy. Far from it. Learning about your buyers this way is far harder than creating content about the technical tradecraft you're comfortable with.

But it's crucial.

If you're an indie, people always tell you to "niche down." And "developer marketing" feels like a niche, so dropping it feels like a step in the wrong direction. It isn't. It's a step down from a low local maximum and toward a higher one.

"Developer marketing" and below-the-brief activities aren't niches because they aren't about your buyers and their outcomes in a meaningful way. As such, it won't help you in identifying niches or positioning (e.g., don't iterate toward "developer marketing for B round companies with purple in their logos"). You need to get above the brief to start having meaningful outcome conversations.

This doesn't mean that you'll stop creating technical content or stop doing service delivery in the world of software or dev tools. You probably won't. But you will realize that developers are just humans and marketing is marketing.

And when you stop mesmerizing yourself with your own tactics, you can make room in your head for strategy—and then positioning.

How We MVP Organic Traffic As A Lead Gen Channel

Erik Dietrich — Wed, 06 Mar 2024 14:47:02 +0000

Minimum viable product (MVP), as defined by Eric Ries in the Lean Startup, is a fascinating term. It has a specific meaning in the context that he defined it, but it also has a highly-inferable, slightly-wrong meaning if you simply happen to know what each of those three words mean. I imagine a whole lot of people have inferred the definition without reading the book:

A minimum viable product is the earliest, feature-poorest version of your product that can survive in the market, right? Right!?

Turns out, not exactly. According to the source:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

I've always thought of the Lean Startup as a book about applying the scientific method to business. And so I've thought of an MVP as an experiment rather than a product, myself. How can you form and then verify or disprove a hypothesis as quickly and cost-effectively as possible? This is the core question of the MVP.

(As an aside, if legibility and lifecycle of buzzwords is a topic that interests you, I once spent a whole blog post musing about this.)

Against this backdrop, I'd like to formalize an offering we've been doing more frequently of late: our organic traffic MVP.

What Is an Organic Traffic MVP?

Our organic traffic MVP is an offering designed to let you learn, as quickly and inexpensively as possible, whether organic traffic can serve as a viable lead gen channel for your business. We work with you to build a small but statistically significant stream of well-qualified traffic to your site and see if you can do something productive with that traffic.

So how is this the least effort? Couldn't you run paid ads or look at a competitor or something? The short answer is no, you won't learn what you need to, and I'll explain in more detail shortly.

And how is this the maximum learning? Wouldn't you learn more with something more precise than "do something productive with the traffic?"

The answer in this case is that you might, but it would veer out of the realm of learning about the channel. Organic traffic to your site is really just a distribution channel. So, the true-north question is whether it can get the right people onto your site and provide you a means of continuing to communicate with them.

The organic traffic MVP is thus Hit Subscribe working with you to produce a small amount of traffic-attracting content, retrospecting with you on the results, and then recommending whether or not to use search traffic as a channel in your marketing efforts.

Organic Traffic MVP Specifics: Cost, Time, and Deliverables

Given that I'm both a longtime consultant and a brevity-resistant writer, you probably assumed I'd hand-wave at the specifics and urge you to book a call to discuss. But what are we even doing if we can't have a little fun subverting expectations from time to time?

First of all, this will cost around $10,000, in some combination of capital and your own labor. And that variability will depend mainly on who you prefer to execute the content.

Speaking of executing the content, the main deliverable will be ten pieces of content that, properly executed, project to rank and earn qualified traffic. Now, obviously that includes supporting deliverables such as our traffic modeling, keyword research, briefing, etc. But at the end of the day, you'll publish ten pieces of content and observe the results.

Why ten? Any fewer than that, and you risk not having enough data for a proper evaluation. Too many more than that, and you're starting to scale before you learn.

And, finally, timeline. How much calendar time should this take? The answer depends on both your timeliness on deliverables and your site's domain authority, but you should think in terms of three to four months, on average.

So, spend $10K over three to four months, and your absolute worst case will be that you feel good disqualifying a lead gen channel and focusing on something else. A much more likely case is that you have a prototype and blueprint for scaling lead gen.

What We Want to Confirm

Now, let's get into the meat of why you should prototype/MVP the channel rather than just pencil it in as a distribution tactic. Here are the things that we want to learn about you in order to recommend hitting the gas, tuning, or abandoning the channel.

Will your editorial vision and ideation tactics for site content prove a blocker for results?
Will or can you remove blockers to the channel's success?
Will your business sustain interest and follow through?
Will the live content hit leading indicators of success in a timely fashion and drive qualified traffic?
Can you do something productive with the resultant traffic?

Throughout the course of (on average) three to four months, we'll answer these questions together. And the ongoing learning will feed into a paradigm that I think of as "succeed, fail, tune, or bail" to help answer whether to scale the channel, abandon it, or make adjustments and continue learning.

And I should also clarify that abandoning a channel isn't a "fail" in the judgment sense but rather in the positive, "fail fast" sense. If search engine traffic isn't a fit for your business, it's better to learn that quickly and move on, rather than hiring an endless series of low-value SEO consultants to tell you to optimize meta descriptions or whatever.

What You'll Learn

So let's dive into the learning. But to set the stage, it's important to understand that the SEO industry has created an absolute miasma of misunderstanding of the channel among non-SEO folks. In other words, the majority of people that come to us subtly misunderstand how organic traffic to their site works.

The most common, and often deal-breaking, type of misunderstanding we see is the idea that you create the content you feel like writing and then "do SEO to it with Yoast or whatever" to make it rank. If this is how you think of SEO, there is a strong chance you're going to fail at the channel. Full stop.

If this is the case, I invite to you to reference my "Are you sure you want organic traffic?" checklist to help you set more realistic expectations around the process. And, yeah, as you are no doubt realizing, this comes up A LOT.

When asked, everyone says they want search engine traffic. Who wouldn't? But it isn't until ideating topics and publishing posts that we really see if they mean it, so to speak.

1. Will Your Editorial Vision and Ideation Tactics Prove a Blocker?

This actually makes for a great segue into describing the first thing that we want to learn about you. If you're currently on team "sprinkle some Yoast on my thought leadership" you're starting out in a success deficit.

Most people tend to think, understandably, of their blog in the original web-log sense. The blog is your brand's journal, where you share insights, wisdom, and novel premises, and you build an audience of steady readers. (Careful here, though, since that can easily degrade into performative content.)

So naturally, you want to ideate about interesting topics that showcase your sophistication. But the problem is this: it's the polar opposite of how you attract search engine traffic.

Searchers are asking fairly mundane, straightforward questions when they take to Google. What does DevOps mean? Or how do I get started with Terraform?

And this means that to rank for "DevOps" and "Terraform tutorial," you have to create content with titles like, "What is DevOps," and, "A Terraform Tutorial for Beginners." Enter: the friction. It's extremely common for marketers and founders to balk at those premises as "too basic."

So let's get this out of the way first and foremost. If that's your take, and you're not moving from it, I can save you the $10K. Don't do organic as a channel—you'll fail.

The good news is that you can have your cake and eat it too. Save your blog for thought leadership takes, and position this content as a glossary or a community tutorial repository or something. Heck, spin up a microsite.

But the first piece of learning here is whether, where, and how you can make peace with organic topics.

2. Will or Can You Remove Blockers to the Channel's Success?

Next up is a much more mundane but equally important concern. Just as SEO has an editorial component, it also has a technical component.

I won't bore you with too many details here (and rest assured, they are indeed boring). But the gist is that we have prospects that come to us with technical problems that would prove a serious headwind for the channel's success. Some quick examples to make this tangible:

Terrible site performance.
A weird, unconventional CMS that doesn't take care of SEO things out of the box.
A history of spam or site problems.
Lack of certain SEO table stakes technical concerns, like sitemaps.

When we engage with clients for campaigns that involve SEO in any way, we do an initial sanity check looking for problems that would be true blockers (as opposed to SEO hygiene minutiae). Usually clients address these things and we move on. But occasionally, if they can't or won't address them, we'd recommend against the channel.

3. Will Your Business Sustain Interest and Follow Through?

I imagine this sounds almost stupid to you as a reader. If you're investing $10K and a few months in a lead generation experiment, wouldn't you obviously stay interested?

You'd be surprised.

Client marketers, especially in the early stages, are wearing a lot of hats. It's fairly easy to find yourself distracted and let signing off on briefs or publishing content slip by another day...or week...or month.

And that's assuming that other, more holistic issues don't crop up. Personnel turnover is incredibly common, site migrations happen frequently, and early-stage orgs tend to pivot.

The amount of ways orgs find to lose momentum would stagger you. It's surprisingly common for us to have to keep nudging clients to finish their part of MVP engagements.

So we want to learn whether or not the channel's success has enough of a role in the business's success to sustain interest. And this is another one that we can really only learn via live engagement.

4. Will the Live Content Hit Leading Indicators of Success in Timely Fashion and Drive Qualified Traffic?

It's interesting that we're on item four here, and it's the first time Hit Subscribe's methodology and deliverables are part of the equation, as opposed to client concerns. But in terms of what we want to learn in chronological order, this is the way it shakes out. A lot of failure patterns occur before the racers even leave their marks.

This is the phase where we'll learn if the content performs on your site the way we hypothesize that it will.

At this point, it's important to revisit the idea that we want to see ten pieces of content so that we have enough data from which to learn. That's because SEO (and I'd argue digital marketing in general) is a game of chance where you stack the odds in your favor, like a casino. The goal is to win the majority of blackjack hands and a steady stream of money while understanding that you won't win every hand.

We'll plan ten posts for you and then monitor them right out of the gate. Google should index them fairly quickly, and then we should see them start bouncing around pages two through ten of the search engine for a few months. If we're not seeing that right out of the gate, we'll do some root cause analysis and try to course correct.

If that happens, we next expect them to settle onto page one and start driving traffic to the site. But I can tell you right out of the gate that maybe eight posts will wind up on page one driving traffic, and maybe two posts simply won't, for reasons no one will ever truly know. That's the nature of the game we're playing here (and anyone who claims otherwise is in the digital snake oil business).

But what we want to learn is whether a predictable majority of them will rank in good position and earn traffic and, if not, why not?

5. Can You Do Something Productive With the Resultant Traffic?

Now we're finally at the end of our learning, chronologically. And we're also at the point where SEO as a distribution channel hands the baton to product marketing and your lower funnel tactics.

You've maintained interest, produced the content, and earned traffic for those efforts. What is that traffic doing? If the answer is that 100% of it is reading the articles and then leaving your site with no further action, then you have a vanity channel rather than a lead-generating one. (Luckily, this almost always fixable.)

Most of the organic visitors to your site will be landing there for the first time and encountering your brand for the first time. So, what next? Do you have a plan for that?

This doesn't need to be perfect, but you should have something in mind. Personally, I think a good litmus test for success is "Do you have a way of initiating a subsequent interaction with this person?"

Here are some examples of what this might look like:

You have a call to action at the bottom of your post that goes to a sales page and prompts readers to fill out a form.
You drop a pixel and retarget them through social media later.
You invite them to sign up for your mailing list or for a webinar.

All of these are relatively light-touch ways for you to continue your conversation with them, and they're also measurable. And crucially, they're all lead pipeline. So if you have these in place and some of the searchers are taking the appropriate action, you have now proven the concept of using search as a lead generation channel.

Examples: Obvious, Marginal, and Non-Fits

If you're reading this and potentially interested in conducting an organic traffic MVP (with our help or just for yourself), let me make things a little more tangible for you. You're likely wondering what fit and non-fit for organic might look like in practice, especially for the "something productive" piece.

With that in mind, let me lay out obvious, possible, and likely non-fit example companies.

First of all, obvious fits. If you have a product offering with a low entry price-point, self-serve sign-up, and autonomous purchasing, it's a fit. In other words, if searchers can land on your site, quickly grok what you do, and buy from you, organic makes sense almost without exception. Think SaaS, productivity tools, retail.

For marginal fits, think of purchase decisions becoming more complex. If the product is more expensive, more complicated, and requires more purchasing consideration, organic becomes less of a no-brainer. In this camp, you'll find complex software, higher-ticket productized services, and small agencies, among others.

And finally, non-fits are companies where "does something productive" is hard to reconcile with a purchase. For instance, imagine enterprise software or global agencies, where commercial purchase decisions involve years-long sales processes and massive buyer committees. Who is going to read an Accenture blog post and say, "Oh, that reminds me, let me get out my credit card and buy a nine-figure consulting engagement"?

(Quick intermediate-level-SEO clarification: I'm not saying Accenture has no reason to show up in search. I'm saying they have no need for an MVP for organic lead gen.)

You Should Test the Channel

I've spent a good number of words here laying out Hit Subscribe's methodology for helping clients evaluate the channel because it's what I know. We've worked with well over 100 brands on organic campaigns. And as our resident traffic modeler, I've had a front-row seat for all of it.

But I want to conclude by saying you should MVP this (and any) lead gen channel whether or not you ever reach out to us. At its core, digital marketing is experimentation and adaption. MVP-ing channels and tactics lets you shorten the feedback loop and iterate quickly to success.

So if you're thinking of trying to bring search engine traffic to your site, sketch out a small prototype first. And crucially, execute it end-to-end—not just on paper. All of your meaningful learning will happen in the trenches.