In my last post, I looked closely at the agentic AI engineering loop: how agentic systems can examine what is happening, narrow uncertainty, propose the next step, and help move real software work forward.

But once agents can participate meaningfully in execution, the operating model around that execution can no longer stay the same. The question is starting to shift from, “can AI help improve the speed or quality of the work?” to “what happens when the work itself starts to change?”

For a long time, the basic way work moves inside product development has looked something like this:

• Product writes

• Design translates

• Engineering implements

• QA validates

• Analytics measures

• Then everyone meets, aligns, revises, and does it again

Even in healthy organizations, a lot of the drag lives in that chain. Work does not just take time because it is difficult. It takes time because it keeps waiting for the next human hop.

Agentic AI is starting to break that pattern. Instead of work crawling through a sequence of handoffs, a person can set the goal, define the guardrails, and give the system enough context to operate. Agents can then do a lot of the first-pass work across the workflow, while humans step in to review, redirect, and make the calls that actually matter.

That is a different execution model.

Making it concrete

Let’s use a B2B dashboard product with a “saved views” feature as our example.

Some customers want to create a filtered view of their data, save it, and share it with teammates. In the old world, the path is familiar. A PM frames the problem and decides priority, design creates flows, engineering starts digging through the codebase, QA gets pulled in later, and a bunch of edge cases surface. Some were in the docs. Some were not. Some live only in someone’s head. So the work starts bouncing around while the team reconstructs how the system actually behaves, where the logic already exists, and which parts are riskier than they first looked.

Now compare that to a more agentic version of the same workflow.

The PM still owns the problem and its priority, the designer still owns the UX quality bar, and engineering still owns system integrity. None of that disappears. But now agents can summarize customer notes related to dashboard view requests, scan the codebase for existing view filtering logic, identify similar patterns, draft a first-pass spec, propose database changes, generate initial tests, and surface likely edge cases before the team gets very far into implementation.

The team still has to decide what is worth doing. It still has to reject bad ideas, catch subtle risks, and make tradeoffs. But the shape of execution changes because the work is no longer bottlenecked by waiting for each function to produce its first draft from scratch.

How the work moves

In the old model, work advances through a chain of functional handoffs.

In the emerging one, the pattern looks more like this: a human sets direction, agents do scoped work across the workflow, and the right humans step in at review points to judge, redirect, and approve.

That may sound like a subtle distinction, but it’s not. It’s a major shift.

When first drafts become cheap across multiple functions at once, the bottleneck stops being draft production and starts being judgment, trust, and making the right call.

Judgment as a bottleneck

If agents can produce ten plausible options in the time it used to take a team to produce one rough first pass, the scarce thing is no longer output. It is deciding what is actually right.

That includes product taste, of course. But it also includes judgment around the technology, priorities, risk, and company direction. Which edge cases matter? Which complexity is justified? Which customer request is loud but directionally wrong? Which polished recommendation is actually nonsense?

The human job is becoming less about generating the first artifact and more about setting direction, applying standards, and protecting customers from a stream of misinformed or half-baked decisions.

What has to get better

This part gets skipped in a lot of the hype.

People see flashy AI coding demos and imagine fast organizational change. The problem is that a lot of software environments were built for humans, and humans have learned how to work around the mess. Agents won’t magically clean it up. They’ll slam right into it.

This problem will show up in a couple big ways:

Documentation

When context is scattered, stale, contradictory, or trapped inside a few people’s heads, it’s annoying and inefficient, but humans can usually limp through. AI will be much less forgiving. If two pieces of documentation conflict, an agent is often going to make poor choices about which one wins, or whether either one is even right in the first place.

Confluence and Notion are helpful to humans, but not nearly as helpful to AI. Sure, agents can access those third-party systems and pull down documentation, but that is often limited by things like the quality of the integration and how long you’re willing to wait for AI to think. It takes time for an agent to query and read dozens of external pages.

For all of these reasons, EPD organizations need to get much more serious about documentation quality and how close it is to the work. Agents get the most leverage from context that is current, well-structured, and just as important, easy to access.

Observability

Agents work better when they can actually trace what is happening in a system. They need readable logs, useful telemetry, and explicit instructions around how to use both.

Don’t have an observability system? Have one but only trained your developers on its UI for an hour a few months back? This won’t cut it.

If an agent is trying to figure out why a KPI dropped 50%, why a feature is timing out under load, or why an exported report disagrees with application data, it needs more than access to your code. It needs an environment where it can ask questions about what’s happening in your systems without guessing. That matters for humans too, of course, but agents will make the gap much more obvious because they very quickly expose just how much of an organization still runs on tribal knowledge and intuition.

Trust

Trust is not all-or-nothing, so the question isn’t whether to trust your agents. It’s which agents will be allowed to do which kinds of work, how that trust will be earned, and how it will be re-evaluated over time. This is more complex than a “human in the loop” solution, since you don’t want humans to end up being the bottleneck for virtually every agent action.

Some output is naturally lower risk: summaries, drafts, first-pass test generation, internal analysis, scoped research, proposed code changes, backlog synthesis. Other work deserves much tighter control: security-sensitive changes, core architecture, pricing, compliance, customer-facing actions, and anything with real blast radius.

The key is that those boundaries should be set based on evidence. There should be more trust when outputs are inspectable, failure modes are understood, drift is detectable, rollback exists, and mistakes are tolerable.

If you cannot tell where the agent helped versus hurt quality, you do not have a trust model. Even then…

Don’t mistake trust for accountability. Agents may help do the work, but a human still owns the outcome. If a team ships something broken, harmful, overbuilt, insecure, or strategically misguided, “the AI suggested it” is not going to be a defensible position. Someone made a call on scope. Someone accepted a recommendation. Someone approved a release. Someone owns the result. That is as it should be.

The org changes too

Once execution changes, the org changes, too. This is where things get more interesting, because the implications are not confined to tooling. They spill into how teams work, what seniority means, how people level up, and why management exists.

Blurred boundaries

Product, Design, and Engineering functions are becoming able to do more across the workflow themselves than before. PMs can do more first-pass technical and analytical work. Designers can prototype and test more aggressively. Engineers can do solution shaping and customer problem analysis.

But the core responsibility of each function also gets clearer. Product still owns prioritization, tradeoffs, and outcomes. Design still owns taste, trust, usability, and coherence. Engineering still owns system integrity, resilience, technical risk, and how not to accidentally burn the place down.

People can do more outside their lane, but the accountability for judgment inside a discipline does not go away.

Seniority

The most valuable people become the ones who can frame a problem clearly, set the right constraints, spot sloppy inputs, and catch misplaced confidence early. Great communication and judgment have always been part of seniority, but we’re moving toward a world where they may matter more than anything else.

Apprenticeship’s comeback

This is one of the parts I think companies are not taking seriously enough.

Juniors probably do not disappear, but the old development path gets shakier. If entry-level growth used to rely partly on getting reps on lower-level work while gradually absorbing context from the people around you, that changes a lot when a meaningful chunk of the grunt work is handled by agents.

Companies will need to be more intentional about apprenticeship, giving juniors opportunities to engage with other engineers while they reason out loud. Otherwise, you risk a weird future where your organization gets temporarily more productive while quietly under-developing its next generation of strong judgment.

Goodbye, weak management

I do not buy the idea that agentic AI somehow makes management less important. I think it will make bad management easier to expose.

If your management value has mostly come from tracking statuses, supervising tasks, or being an approval bottleneck, agentic AI is going to expose that quickly. In an agentic world, management work will look much different: written quality bars, clear escalation paths, codified trust boundaries, solid instrumentation, and constant coaching to improve judgment.

Why this is hard for many teams

Part of the friction is identity. A lot of people built mastery over their work. They like doing that work directly. They like refining their craft. And honestly, that is understandable. Some of the resistance people call “anti-AI” is really attachment to the part of the work that used to feel satisfying in the first place.

There is also a second problem. The shift is not just about new tools. It is about moving from task execution toward problem framing, systems thinking, constraint setting, and judgment. Those skills are not evenly distributed, and they are not skills most organizations have spent years deliberately training at scale.

And to make things more fun, the technology itself is still moving fast while teams are trying to redesign how they work around it. So companies are being asked to change the plane while still flying it.

Ultimately, this transition requires real change management: education, process redesign, organizational alignment, room for experimentation, room for mistakes, and enough seriousness to not let “AI adoption” turn into theater. That competes with near-term priorities, of course. But not investing in that transition has a cost too: slower learning, weaker leverage, and having to watch while faster teams lap your own.

Final thought

The companies that win here will not be the ones that talk the most about AI, buy the most tools, or generate the most internal excitement. They will be the ones disciplined enough to redesign their actual operating model around the reality that:

• First drafts are getting cheaper.

• Judgment is getting more valuable.

• Shared context, observability, and trust are table stakes.

Agentic AI is not just a productivity layer bolted onto the old EPD model. It is creating a new model, which means that management, seniority, apprenticeship, trust, and accountability all have to change with it. This is the harder shift. It is also where the real advantage will come from.

A special thanks to my colleague, Tom Schaal, for his assistance in identifying the change management challenges arising as EPD orgs shift to an agentic world.

A lot of the conversation around AI and software engineering is still missing the point.

Some people are stuck on whether AI will replace engineers. Others are captivated by flashy demos where a disposable prototype gets spun up in 10 minutes. Both conversations are too shallow. They do not really explain what is changing in the work itself.

I usually prefer to write at a higher level of abstraction than I’m going to here. But sometimes a shift in how work gets done is significant enough that you have to zoom all the way in before you can say anything useful about it. This is one of those cases.

A few years ago, models started to write buggy code in small bursts. That was interesting, but not enough to change the work. The latest agentic tools are different. Claude Code, Codex, and similar systems on the latest models can now participate in much more of the engineering loop than most people appreciate. They can inspect environments, read logs, reason through failures, propose next steps, generate scripts, document discoveries, and help turn messy progress into cleaner systems. That is a very different thing than a code assistant that mostly helps you type faster.

The project: a real modern system, not a toy

I wanted to pressure test that for myself.

Not with a cute prototype app or a carefully staged demo. I wanted a project that was both relevant and difficult. I wanted what I built to capture the complex underlying architecture driving the type of end-user value many EPD teams are chasing today: enterprise search, internal knowledge systems, support copilots, and agent memory layers.

So I spent the better part of a Sunday building a complete system that could pull information out of tools like Jira, Notion, and Readwise Reader, store it in one place, make it searchable by semantic meaning rather than just keywords, and expose it through a simple API for apps and agents to use. OpenAI’s Codex helped drive the engineering work from start to finish.

What I actually built

Although no one piece of this architecture was novel, the project crossed several engineering layers at once — infrastructure, container setup, data syncing, database connectivity, schema inspection, search and retrieval design, API exposure, and day-to-day operator workflow.

Starting from an empty repo, I ended up with a repeatable environment bootstrapping toolset and operator workflow built around:

• A data-ingestion tool (Airbyte)

• Containerized services (Docker)

• A database (Postgres) as the system of record

• A shared search layer (pgvector) across multiple sources

• A small local API (written using Flask)

• A repo-local setup for AI skills and documentation so onboarding and maintenance into the project didn’t require the AI to constantly re-learn the environment from scratch.

It was a great stress test because there were plenty of potentially messy failure modes.

And agentic AI rose to the challenge. Only 1 day, 17 chat threads, and a few dollars later, I went from “let’s see what happens” to a working local system that could pull scattered information into one place and let apps or AI search and use it. That local system also had a clear path to cloud infrastructure run at scale.

The ground that is shifting beneath our feet

The scope of engineering work AI can now help meaningfully drive is much larger than most people think–as long as AI is utilized properly.

This was not a one-shot miracle where AI delivered a shiny UI that only half-worked under the hood. And yet, in only 17 rounds of iterations, AI did much more–it brought to life some of the most robust backend plumbing possible.

So, if your model of AI-assisted development is still “prompt in, code out,” you are behind the curve.

The real advance is that these tools can now work with you inside the actual loop of engineering: inspect the current state, form a grounded hypothesis, make a targeted change, verify what happened, react to the evidence, and help turn the discovery into something durable.1 That loop is where real engineering lives. Most projects are not about writing isolated code snippets. They are about figuring out what is true in a messy environment, reducing uncertainty, and making the next good decision.

This project meaningfully advanced my mental model of what AI was capable of yet again.

The biggest ‘aha’: compressed exploration

Normally, a project like this is full of dead time. You hit an issue, lose momentum, start cross-referencing docs, try a few fixes, realize the problem is somewhere else, and slowly bleed context as you go. The newest agentic tools dramatically reduce that friction. They help you hold context longer, narrow the search space faster, and keep moving.2 A lot of leverage in engineering comes not from raw code production, but compressing the time between “something is wrong” and “I now know the next best step.”

That is the part many people still do not understand.

Here are the AI-first practices that I found mattered most:

1. Use AI as an engineering collaborator, not a code generator.

That sounds obvious, but it is a very different stance in practice. I was not asking for giant blobs of output and hoping they worked. I was using AI to help understand the current state, propose the next step, implement a focused change, and reason about the result.

Early on, for instance, the challenge was getting my Airbyte install to behave reliably. The wrong approach would have been to ask for one massive setup script and pray. The right one was to work in short loops: install, verify, inspect failures, patch the setup, rerun checks. That is how issues like stateful login behavior, system resource requirements, and install detection quirks actually surfaced.

2. Force AI to inspect, not speculate.

This may be the most important habit of all.

AI gets dangerous when it is allowed to answer from generic memory instead of the real system in front of it. So throughout the project, I kept grounding it in evidence: command output, logs, row counts, actual database schemas, service behavior, failed sync details.

That changed the quality of the work substantially. When one sync failed, for example, the easy answer would have been the usual suspects: bad credentials, bad networking, bad destination config. But the live evidence showed the source and destination connections were both fine. The actual issue was a stale cursor configuration on one data stream. That is a very different diagnosis, and it leads to a very different fix.3

3. Keep the work in short, testable loops.

This sounds simple because it is simple, but people ignore it constantly.

When AI is involved, the temptation is to hand it a huge objective and hope. That usually backfires. The better pattern is to define crisp checkpoints. If you are adding a new source to a data retrieval pipeline, do not start with “index everything perfectly.” Start with “can one real document make it all the way through the path and show up correctly in the retrieval tables?”

That kind of smoke test reduces ambiguity, limits the surface area, and gives both you and the model something concrete to reason against.

4. Give AI local context so it stops acting like a tourist.

General model knowledge is helpful, but it is not enough once you are deep into a specific workspace.

In this project, I encoded repo-specific operating knowledge into AI skills and documentation: what the repo actually was, how the operator flow worked, what the landed data schemas looked like, how the data retrieval layer was organized, and which commands actually mattered. The difference between an AI that vaguely understands Airbyte and one that understands this exact workspace’s Airbyte setup is enormous.

Same model. Totally different leverage.4

5. Turn discoveries and misses into durable assets immediately.

Every real project uncovers annoying truths. The normal temptation is to solve them once and move on. That is a mistake.

When you discover the exact sequence needed to make a host database reachable from containers, the right defaults for a setup flow, or the specific verification command that tells you whether the environment is actually healthy, capture that right away in a script, a check, a skill, or documentation.5

The same goes for misses. When the model makes a bad assumption, or when a specific type of task clearly requires grounding in live data rather than generic knowledge, the answer is not only to fix the current issue. The answer is to improve the surrounding guidance so future work starts from a stronger place.

This is one of the most underappreciated ways to compound gains with AI. Most people treat every session like a clean slate. That leaves a lot of value on the table. AI is very good at helping turn what you just learned into something cleaner and more reusable. The win is not merely solving a problem once. It is making the next feature, the next bug fix, and the next session cheaper.

6. Refactor aggressively. It’s cheap.

One of the more interesting architectural lessons here was how helpful AI was in moving from point solutions to shared patterns.

It would have been easy for the semantic search layer to stay tightly coupled to the first data source it worked against. That is how a lot of internal tooling evolves: one hyper-specific success at a time, followed by quiet duplication without stepping back to make a DRY pattern. I was able to avoid that by asking AI to refactor things–quickly and efficiently–after the same concepts were duplicated two or three times.6

AI did not proactively surface those refactoring opportunities for me. But it was very helpful in accelerating the refactoring itself when prompted.

That is a bigger deal than people think. If refactoring and generalization get cheaper, teams should expect better internal architecture, not just faster delivery.

What this means for engineers

For individual engineers, I think the takeaway is straightforward: the highest-leverage way to use AI is not as a faster typist. It is as a collaborator in debugging, exploration, and system design.

That matters because the highest-value part of engineering isn’t writing code. It is inspecting reality, forming hypotheses, reducing uncertainty, choosing the next best step, and turning discoveries into durable systems. AI can now participate meaningfully in that loop. But the loop still requires judgment, prioritization, tradeoff-making, and interpretation. That is why engineering is also a human domain.

If you use these tools like a vending machine, you will get vending-machine outcomes. If you use them inside a disciplined loop — grounded in evidence, broken into short checkpoints, and constantly converted into reusable knowledge — you can move through real engineering work much faster without making the work sloppier. That is not a replacement for all aspects of the broader engineering discipline. But it does meaningfully change the repetitive daily loop.

What this means for engineering leaders

For leaders, the question is larger than developer productivity.

If you evaluate AI only through the lens of lines of code, tickets closed, or hours saved, you are asking too small a question. The more important question is whether your team knows how to use these tools to reduce uncertainty, ground decisions in evidence, structure work into short loops, turn discoveries into reusable assets, recognize when point solutions should become shared systems, and build the kind of project-specific context that helps AI stop guessing and start working from reality. As the underlying models improve, these skills will only matter more.

AI greatly amplifies strong human habits. But if your team has weak ones, AI often gives you more noise than signal. “Garbage in, garbage out.”

That is why I came away from this project less interested in the usual “AI replaces engineers” conversation and more interested in operational fluency. The organizations that get the most out of this moment will not be the ones ignoring it, chasing the loudest demos, or freeing up dollars paid to engineering staff. No, it will be the organizations that encourage engineers to best guide these systems, verify them, shape the context around them, and work with them in a disciplined, grounded, compounding way.

That is the real advantage.

Next up: The EPD operating model

What I’ve written here is mostly about the engineering loop itself: how agentic AI changes the day-to-day mechanics of building, debugging, and refining software. The even bigger story is organizational, not just individual. Soon, I’ll be doing a deeper dive on what I believe this means for the EPD operating model: what becomes the new unit of execution, where judgment and accountability move, how teams should be structured, what happens to juniors, and why shared context, trust, and evaluation start to matter more than ever.

94f214c 10:53 first commit
2eb9dab 13:19 postgres instructions
1d8beb4 15:37 Enable the Airbyte builder
3847ec8 17:53 Jira vector search
6b3d7b2 18:44 Generic vector search
1e47302 19:40 New Notion skill
cd7887f 20:28 Notion AI vector search
9a5c040 20:43 Readwise Reader AI vector search

$Airbyte Local CE Expert    I'm running into issues using the Jira source. See the attached logs. What seems to be the problem?

The main problem is not Jira connectivity. The Jira source check passed, the Postgres destination check passed, and schema discovery also passed.

The sync then fails during destination initialization because Airbyte thinks stream `jira.issues` is configured with a cursor field that is not present in that stream’s schema. The key error is: `For stream jira.issues: The cursor does not exist in the schema`.

So the likely issue is:
- that stream is set to incremental / deduped mode with an invalid cursor field, or
- the stream schema changed after discovery and the saved cursor selection is now stale.

What to do in Airbyte:
- Refresh the source schema.
- Open the `jira.issues` stream config.
- Re-select a valid cursor field if incremental is intended.
- If that stream has no usable cursor, switch it to full refresh / append instead.

The Postgres connector is just where the validation trips; it is not the underlying problem.

Start from the `ntn` schema in Postgres. Confirm the actual tables, row counts, column types, and nested storage shape before writing SQL or making schema claims.

- Treat the landed destination schema as the source of truth for implementation details.
- Use Notion API docs to interpret meanings, not to override what actually landed in Postgres.

CREATE TABLE IF NOT EXISTS jira_ai.vect_issues (
  issue_id text PRIMARY KEY,
  ...
);

CREATE TABLE IF NOT EXISTS jira_ai.vect_issue_chunks (
  issue_id text NOT NULL,
  ...
);

CREATE TABLE IF NOT EXISTS ai.documents (
  document_uid text PRIMARY KEY,
  source_type text NOT NULL,
  source_instance text NOT NULL,
  source_document_id text NOT NULL,
  ...
);

CREATE TABLE IF NOT EXISTS ai.document_chunks (
  document_uid text NOT NULL REFERENCES ai.documents(document_uid) ON DELETE CASCADE,
  source_type text NOT NULL,
  source_instance text NOT NULL,
  source_document_id text NOT NULL,
  ...
);

Early on in your journey, learning how to control what you do with fear when it shows up is one of the most important investments you can make in yourself.

Do you freeze?
Do you negotiate yourself into doing nothing?
Or do you use it as a signal that you’re standing at an edge that might actually be worth crossing?

Fear doesn’t show up the same for everyone

People who’ve already taken a bunch of scary swings, or who have more of a safety net, often feel less fear because the downside is smaller.

For example, in a professional setting, if you’ve:

• built up some savings

• proven to yourself that you can land another job

• taken risks before and survived

… you’re not experiencing the same type of emotional reality as the person standing at the edge for the very first time, with no cushion and no track record.

The context matters.

So what is fearlessness, actually?

Simply put, it’s making intelligent bets on yourself or the people around you even when they’re not safe or popular bets.

Note that this is different than betting recklessly or betting to boost your ego.

Over time, you win more intelligent bets than you lose, and that track record compounds. The first ones feel like jumping off a cliff. But the tenth, more like a curb.

Three bets that rewired how I think about fear

A lot of my day-to-day work now involves risk in one form or another. But the more interesting examples for me sit a decade or two back, when I had far less safety and privilege to lean on.

1. Dropping out of college to pursue a startup

I dropped out of college after a year to pursue a startup.

My parents were solidly middle class. A lot of my friends were doing the safe law/finance degree path. There was a very clear script for what “smart” looked like, and this was not it.

It was uncomfortable as hell.

On paper, this wasn’t a perfectly modeled decision. But I had a strong conviction: I cared more about building things in the real world than optimizing for a traditional resume.

The lesson is definitely not that everyone should drop out.

The lesson is: you’re allowed to make a bet you deeply believe in, even if it makes other people uncomfortable. Once you’ve done that once, it gets easier to do it again when the stakes are different.

2. Pitching a media publishing conglomerate on a product that didn’t exist yet

In my early 20s, my cofounder and I did cold outreach to media publishing conglomerate to sell a product we hadn’t even built yet.

It was terrifying.

I remember rehearsing ours lines beforehand, trying to sound like the kind of people they should take seriously.

But here’s the thing: the bet was smart.

• We knew the problem they had.

• We knew we could build what we were pitching.

• We knew that if they said “no,” we’d still learn why and be better off.

They said “yes.”

That outcome reinforced something important: the emotional cost of fear is often wildly out of proportion to the actual risk you’re taking. The upside of moving anyway is bigger than it feels in the moment.

3. Pushing for parental leave at an early-stage startup

Fast forward a bit. I’m an executive at an early-stage startup, in a time when parental leave still isn’t common in that environment.

I pushed the founders to authorize a healthy amount of company-subsidized leave for all employees.

This wasn’t a convenient ask. It wasn’t aligned with some meticulously planned budget, and I didn’t have much to gain personally.

But it was plainly the right long-term call for the team:

• It signaled that we actually cared about humans, not just headcount.

• It made it more realistic for people to stay and grow with the company.

• It widened the door for who could even consider working there.

So I pushed. And we did it.

Of course, it ended up helping morale, diversity, retention—all the stuff leaders claim to care about on slides.

The founders warmed up to it once they saw the impact. But the moment that mattered was the one where it was still uncomfortable and unpopular, and we did it anyway.

Fearlessness as a habit, not a personality trait

If there’s a thread running through these stories, it’s this:

Build the habit by repeatedly taking smart bets when it’s not easy, so that the next time, there’s a bit more privilege to lighten any potential fall.

Ultimately, the goal is to get to the point where that little voice in your head telling you to back away from a situation instead becomes the very voice telling you when a situation matters enough to pay attention and engage.

The response to that post was significant. I received quite a few comments proclaiming how rare it was to find an engineer that fit the bill.

That’s fair!

But it’s not because only a tiny sliver of engineers are capable of working this way. They’re rare because very few engineers are ever taught to optimize for these skills, and even fewer companies reward them during the initial hiring phase. So the market ends up under-producing exactly the kind of talent it desires.

This post is for the engineers who want to be in that “rare” bucket.

The two axes that actually matter

Think about your career along two simple axes:

1. How you work

   • One-speed executor: Same energy everywhere, vs.

   • Master of context: Being willing to change gears

2. What you work on (the skill frontier)

   • Established terrain: Mature, saturated technologies, vs.

   • Western fronts: Domains where the rules are still being written

While these axes describe the mechanics of your work, there is also an operating system underneath: product thinking and customer centricity. This operating system determines whether those mechanics actually translate into meaningful outcomes.

The engineers who advance fastest today live in the top-right corner of that map:

• They deliberately choose frontier domains; they work on the right stuff.

• They’re masters of context in how they work, and guided by a clear understanding of customer outcomes.

That combination is what I call the Western Front Innovator.

Today’s post is about how engineers struggling to progress professionally can intentionally steer their careers toward that top-right corner.

Step 1: Stop trying to win other people’s game

If as part of your journey, you find yourself asking questions such as:

“How can I progress with learning React?”

or

“How can I become an expert with Kubernetes?”

Stop right there!

Swarms of others have been developing expertise with technologies that emerged last decade for… at least a decade. It’s already their superpower. It’s unlikely to become yours, too.

When you chase mature stacks as your primary differentiator, you’re signing up to compete with people who have a massive head start. You’re playing their game on their field, by their rules.

This is no way to become “rare.”

Step 2: Move to the frontier

Ask yourself:

“What is emerging right now? Where are the rules still being written such that nobody has an insurmountable head start?”

Today, that’s a few areas, including but not limited to AI engineering – specifically the intersection of data pipelines, backend systems, and LLM-driven product development. I’ll focus on this example.

Now, let’s be clear. Despite what many job requirements and LinkedIn titles would have you believe, there’s no such thing as an “AI Engineer” in any deeply meaningful sense. There simply can’t be. A junior engineer who spends six months learning this stuff today is approximately as “experienced” as almost everyone else on the market (assuming they understand the CompSci fundamentals that underpin it).

In other words, being an AI Engineer doesn’t mean having a wealth of specialized experience. How could it, possibly?

It means being hungry to experiment. Quickly. And consistently. It means you’re willing to live on a moving frontier where the docs are incomplete, patterns are still solidifying, and nobody can pretend to have a decade of authority.

This is the first half of the Western Front Innovator: you choose to live on the frontier.

Step 3: Become a master of context in how you work

This is the area where the first post went deep.

Being a master of context boils down to a simple principle: You adjust your engineering approach based on the stakes and the outcome you’re trying to achieve, not your habits.

Step 4: Treat product thinking and customer centricity as the operating system

This isn’t a separate “step” or a bonus skill sitting off to the side of the model. It’s the operating system that makes both axes work.

Without product thinking and customer centricity:

• Context switching turns into over‑engineering or reckless hacking.

• Frontier work turns into hype‑chasing.

With them:

• Context switching becomes deliberate: you know when speed matters and when reliability matters because you understand the customer outcome you’re aiming for.

• Frontier work becomes meaningful: you’re not just playing with new tools — you’re using them to solve real customer problems in ways that weren’t possible before.

This is why Western Front Innovators behave differently once they reach a frontier domain. They:

• Start backwards from customer outcomes, not just stories and tasks.

• Ask, “What is the actual job‑to‑be‑done here?”

• Push on why a feature matters and what success should look like.

• Are willing to reshape the solution when the outcome demands it.

Now mix that mindset with frontier tech and the whole picture changes:

• Instead of saying, “Give me tickets,” they say, “If our customers struggle with X, there’s probably a way to combine this new AI capability, this data we already have, and this workflow to solve it in a way that didn’t exist a year ago.”

These engineers don’t just ship features. They ship novel outcomes. And those outcomes get noticed fast.

Step 5: Leave the excuses behind

Unfortunately, you may find yourself saying:

“I can’t find opportunities that give me the space to do what you’re suggesting.”

Make your own opportunities. Use some downtime to wow your colleagues with a new direction. Work on side projects and/or start your own freelance to build up a portfolio. Do absolutely anything but blame your job or the market. Ultimately only you are responsible for ensuring you grow the way you want. Remember that.

Also, good news…

The engineering landscape is shifting

Historically, companies haven’t hired nearly enough Western Front Innovators. They optimized for narrow speed (ship tickets) or narrow craftsmanship (polish small, stable areas) rather than people who could steer and adapt.

AI-assisted development is already changing the landscape. As the raw mechanics of coding get easier, the premium is quickly moving toward:

• Deciding what to build.

• Deciding how fast to move.

• Deciding where new tools can reshape the problem altogether.

In this world, Western Front Innovators aren’t only nice to have on a team. They’re absolutely critical. And this means companies will soon have no choice but to begin more purposefully seeking them and fostering their growth.

Design your career toward the top-right

If you’re a software engineer looking for an edge, don’t just collect tech buzzwords and hope that translates into some vague idea of “senior.”

Design for the top-right:

• Avoid building your whole identity around stacks that are already saturated.

• Move closer to frontiers where experience is in short supply.

• Lean hard into customer centricity and product thinking.

• Practice context switching on purpose: prototype here, craftsmanship there, and be explicit about why.

There always has been inherent demand for engineers who can do this (even if job postings don’t overtly advertise it). And moving forward, I believe this inherent demand will quickly turn explicit.

So in a world filled with engineers sprinting toward other people’s superpowers, opt out. Create your own. Be a Western Front Innovator.

No, they’re masters of context.

They can duct-tape together a prototype with caffeine and determination and are also the ones you trust to slow down, take a breath, and treat a fragile system like a surgeon.

That gear shift is the whole ballgame. And most engineers never develop it. In fact, I’ve noticed many don’t even realize it exists!

Yet, for a lot of companies, this is the difference between “we’re moving fast” and “we’re accidentally burning the place down.”

Prototype → production whiplash

If you’ve worked in a fast-moving product org, you’re familiar with the whiplash. One hour you’re validating a feature with a scrappy, “don’t look too closely” implementation. The next hour you’re diving into a part of the codebase where a single careless change could bring the whole house down.

The rules don’t just change, but the environment does. One mode rewards improvisation while the other punishes it.

Great engineers appreciate this difference instinctively. They don’t need to be reminded. They don’t need someone following them around with a checklist. They just read the room and adjust.

Meanwhile, context-blind engineers treat everything with the same energy: either full speed or full ceremony. They refactor a prototype as if it’s a financial system or treat a production path with the swagger of someone who’s never been paged.

What you should actually be hiring for

Whether you’re a seed-stage startup or a public company trying to rediscover its edge, if you’re hiring, look for someone who can prototype on Monday, validate the idea on Tuesday, and then — without being asked — switch into craftsmanship mode on Wednesday.

In interviews, ask about the pace changes:

“Tell me about a time you needed to move fast.”
“Tell me about a time you needed to slow down.”
“How did you know which was which?”

Listen carefully. You’re looking for self-awareness and a willingness to adapt. Someone who treats engineering as more than just a single skill.

Because that’s who you want in the room when your company says, “We need to innovate faster,” but also, “We cannot afford outages.”

The real superpower

Whether you’re chasing product-market fit or modernizing a legacy platform with millions of users on it, chances are really good that you’re look for engineers who can shift pace and precision fluidly based on what the moment demands.

When you find them, don’t let them go! They’re the ones that will see to it that your company evolves quickly without burning down.

Near my house, there’s a covered bridge which has always displayed its clearance height. But trucks would occasionally hit it, so the town recently decided to get more aggressive — by adding a dangling clearance marker that physically hangs a few inches below the bridge itself.

The recycling truck that comes through every week has always fit just fine under the structure. But now? It can’t get past the dangling clearance marker.

The result? A routine that worked perfectly for years suddenly hit a roadblock — not because of some major change, but because nobody considered the potential negative consequences of adding this seemingly helpful and benign marker.

For me, this was a perfect analogy for software product engineering. Just like that clearance marker, seemingly minor bug fixes or improvements can create ripple effects that disrupt user workflows in ways we don’t anticipate.

Software is used in the wild

Tiny adjustments to software can lead to meaningful behavioral shifts downstream. This is especially true in enterprise environments, where users often rely on complex and rigid processes. Changes — no matter how minor they seem — can catch users off guard, leading to significant frustration.

In the case of the bridge, no one checked the height of the neighborhood recycling trucks. No one communicated the addition of the clearance marker to the key "stakeholders". Sound familiar? Too often in product engineering, we overlook the broader impact of a change because we’re focused on the specs, not the humans.

How to avoid the “clearance marker moment”

So, how do great engineering, product, and design teams avoid the clearance marker moment? By abiding by a few key principles:

1. Engage key stakeholders early: Especially in enterprise software, involve users, admins, and partners in your planning. Their input can help you identify potential pain points you might miss.

2. Put yourself in the user’s shoes: Step back and think about how your users interact with your product in the real world. What workflows, tools, or systems depend on the change you’re making?

3. Test for edge cases: Just because something works in theory — or in your testing environment — doesn’t mean it will work for every user. Account for those “recycling truck” scenarios.

4. Communicate proactively: If there’s even a hint that your change might cause confusion, over-communicate. This includes announcements, user guides, and contextual messaging within the product itself.

5. Experiment: In a software context, experiments can be run on small segments of users. Consider rolling out changes slowly so that you can monitor impact.

Promoting trust

Bottom line, users need to feel confident that your product won’t throw them curveballs, especially in environments where reliability is critical. Every time you dangle a clearance marker in their previously uninterrupted path, it puts a dent in their relationship with your product.

So the next time you’re debating a minor change, ask yourself: “Is this a bridge that’s in the user’s critical path?” If the answer is yes, make sure you’re considering the vehicles that actually cross it — not just the ones you originally designed for.

Recently, I had the pleasure of speaking with Lindsay Tabas on her video podcast. Lindsay is a product-market fit strategist, innovation consultant, and venture fundraising advisor.

Whether you're pumped about AI taking over the world or feeling like it's time to ditch social media and live off the grid, Lindsay and her guests break it all down so you can actually understand what's happening.

In this episode, we discussed:

• The impact of democratized AI and low-code tools on engineering teams

• College degrees vs. experience as a tech worker

• The difference between software developers and engineers

• The art of the MVP

• What shadow IT is and how organizations need to adapt

• Waste and complexity in product organizations:

  • How cheap capital enabled it

  • Its relationship with user experience

  • How zero-based, objectived-focused resourcing is the solution

I hope you enjoy it and find value that - as Lindsay would say - helps you ‘design the human experience into the future’!

Most of us are familiar with Goodhart’s Law, which tells us that:

“When a measure becomes a target, it ceases to be a good measure.”

In this way, I believe that many popular enterprise SaaS metrics have lost their efficacy over time. But there is one that I want to talk about today because it has become particularly egregious — Net Revenue Retention (NRR).

For anybody who requires a refresher,

NRR measures a company’s ability to retain revenue

It is the company’s starting recurring revenue, plus/minus any recurring revenue gained/lost by the existing customer base during the financial period, divided by the starting recurring revenue.

So at 100% NRR, a company can confidently state that its customer base is paying the same amount to the company at the end of the financial period as at the beginning. Useful!

So what’s the problem?

Investors, bankers, and suitors are addicted to this metric.

I believe this is the case for two reasons:

First, a shared view exists that NRR is an effective way to link customer success with revenue outcomes, and thus is a useful way to measure the health of the whole business in one snapshot.

Here’s what WallStretPrep has to say about it:

“… the higher the NRR, the more secure a company’s outlook appears, as it implies that the customer base must be receiving enough value from the provider to remain.”

And Stripe:

“A high NRR indicates that a company is not just successfully retaining customers and growing revenue through upsells and expansions, but delivering an experience and products that their customers love.”

The second reason the addiction persists is that NRR is a metric that’s easy for leadership to effect change around quickly, which makes it a convenient point of leverage for raising new funding, going through M&A, and much more.

As a result, the enterprise SaaS community has become so obsessed with NRR as a golden metric that it typically a) holds customer success teams directly accountable to it and b) underemphasizes metrics that are more directly indicative of customer satisfaction.

But does higher NRR in fact mean happier customers? Or better account longevity?

Ask 100 different enterprise SaaS operators and you will get 100 diverse answers to this question. But off the record, enough of these answers will boil down to a “no” to make one squirm.

Read between the lines and what’s happening becomes clear: Company leaders and their investors are surrounding each other in a reality distortion field. It’s easier and more lucrative in the short-term to expand an existing account than it is to preemptively save the entire account in the future. So they prioritize expansion revenue at the expense of customer satisfaction, and call it all a win because NRR hovers at or above 100% in the short-term.

But why is the notion of expansion revenue as an antidote flawed?

Generating expansion revenue requires resources

Whether it’s a land and expand play, pushing newly minted functionality as an upsell, or both, a huge concerted effort is required between the GTM, product, and engineering organizations to strategically expand revenue on existing accounts. As a result, far more resources are needed in each of these orgs than if the expansion were more organic.

Because nobody wants to increase operating expenses, new heads aren’t hired; existing heads are simply shuffled around projects.

What suffers? Innovation tracks that help successfully land new logos grind to a halt.

What’s the eventual outcome? ‘Bad fit’ customers are brought on to compensate for poor logo growth, and those bad fits are even tougher accounts to retain and expand against. The negative feedback loop continues.

Expansion revenue often becomes hostile to customers

Have you ever gone through a painful process to resolve an issue with your telecom company — just for them to have the gall to try to sell you an upgraded package at the end?

If so, this is personal.

Who suffers? Just because a company is able to expand the monetary value of its accounts over a relatively short period of time does not mean its customer base is happy or will remain loyal over longer periods of time.

What’s the eventual outcome? NPS goes down, churn goes up, and expansion revenue becomes even more important as time goes on. The negative feedback loop continues.

Averages are skewed by extremes

It's all too common to see a game played where a small minority of key enterprise accounts go through a massive expansion while the rest of the customer base loses value. NRR shows up at or better than 100%, which is fantastic, but the real story is that a handful of CSMs or AEs have had a great month.

Who suffers? Customers.

What’s the eventual outcome? Need we repeat ourselves?

The solution is in plain sight. But so difficult to accept.

More traditional customer success metrics should be utilized to understand the long-term health of the customer base!

I’m not here to teach you about those other metrics, though. You already know what they are. I’m here to talk about why those metrics are often deprioritized despite their importance:

Our shared addiction with NRR.

Like many addictions, there is a reason NRR is so enticing in the short-term. NRR provides a quick fix to a problem, and negative consequences are deferred to the long-term — usually for future leaders or investors to clean up.

It’s time to get back to building startups for the long haul.

The relationship between influence, authority, and leadership is often confused.

People follow those with authority out of obligation, and those with influence out of conviction. But something interesting happens when a single person accrues enough influence — They’re anointed ‘authoritative on X’.

The typical eventuality of a person exerting strong influence, consistently, is them being granted some amount of elevated authority - whether they want it or not!

It is my belief that this marks the difference between an influencer, an authority figure, and a leader. Influencers and authority figures can both exist independently of each other, but a leader must be both.

But how do people gain influence, use influence to gain authority, and then as leaders, use the two appropriately as the situation calls for it?

Influence can be the outcome of personal conviction and extreme risk-taking.

Take Ken Kutaragi. The year was 1984. Ken was an engineer at Sony when he created a prototype for PlayStation in secret. He faced significant resistance from senior management once it came to light, but eventually, managed to gain the support of key Sony executives due to pressures such as the allure of the prototype and interest from Nintendo. PlayStation went on to become one of Sony’s most successful products, revolutionizing gaming in the process.

Ken influenced his superiors as a result of his own conviction. And then he acquired lots of authority as CEO of Sony’s brand new video game division.

This type of influence isn’t usually sustainable, without also building long-term trust and credibility.

Influence is more typically earned slowly, via social currencies.

Let’s look to Anne Mulcahy, whose rise to CEO of Xerox is a masterclass in building up these social currencies. Starting in sales in 1976 and moving through HR and marketing, she built a deep understanding of the company and cultivated strong relationships. When Xerox faced a financial crisis in 2000, Mulcahy, though not initially in top leadership, was unexpectedly appointed CEO. That’s because she had already been tackling tough challenges and building trust across the organization for years prior. Her decisive actions, including cost-cutting and strategic refocusing, saved Xerox from bankruptcy, solidifying her reputation as a leader who could guide a company through its most challenging times.

In short, Anne built up trust and credibility organically, over a very long period of time, and amassed power over that same time rather than all at once.

Once influence and authority are both in strong supply, a leader must continually inspire and guide colleagues in committing to decisions that stand the test of time.

This is the only way trust and credibility can grow over the course of a career. And if we’re keeping track, trust and credibility are the social currencies required to retain influence.

With waning influence, a person in a position of power increasingly becomes an authoritarian ruler. This works for a period of time, but doesn’t last. Continued trust and credibility prevent such a fate.

Of course…

Timeless decisions aren’t easy!

It can’t be overstated that for a series of decisions to be considered timeless, they must lead to successful outcomes for most stakeholders over the long-term. It is extremely difficult to make such well-considered, holistically balanced decisions.

Yet this is exactly what Satya Nadella did when he took over a stagnant, irrelevant Microsoft in 2014.

His most significant, timeless decision was to encourage employees at all ranks in the company to shift from a “know-it-all” culture to a “learn-it-all” culture. Simple, right? Except Microsoft’s prior dominance was a result of its accumulated knowledge and power. Would admitting it needed to completely unlearn its past actually serve it well?

In fact, yes. This growth mindset led to a series of strategically sound decisions for Microsoft such as acquiring LinkedIn, bolstering up Azure by integrating core products + GitHub into its ecosystem, making Windows compatible with Linux, and partnering with OpenAI.

So it all comes down to this…

Leadership is about balance.

It’s about demonstrating through actions when it’s prudent to move fast vs. slow. It’s about deciding — often quickly, and instinctively — when to acquiesce and when to push back with every fiber of one’s being.

Getting that balance right is what stands the test of time. It’s what grants a leader both the influence and authority to lead for decades.

There's a narrative that’s been circulating around the venture backed startup community over the past year or so. It goes something like this: For about 15 years, interest rates were zero or near zero. This made money cheap to borrow and it made it tough for investors to find high growth places to put it. So investors stashed their money in higher risk, higher reward vehicles like venture capital funds for startups -- and startups were incented to take that money because it was so cheap. Now that money isn't cheap anymore, the party's over.

For anybody who remembers subprime mortgages circa 2007, this should ring a bell. Leading up to that crisis, banks made it way too easy for average folks to take out mortgages well beyond their means. Not everybody participated. But a huge chunk of the population either exploited or fell victim to the phenomenon.

It was easy at the time to blame foreclosure problems on the banks. And it's easy now to blame some of the economic hardship in tech on interest rates. But to be a startup owner or operator at scale is not the same as being an everyday citizen… At least, it shouldn’t be.

Lately, my LinkedIn feed has been absolutely inundated with nonsense about zero interest rate phenomena.

Over-engineered all the things?

✨ Zero interest rate phenomenon.

Hired way more heads than necessary?

✨ Zero interest rate phenomenon.

Acquired customers at a huge loss figuring they'd monetize later?

✨ . . .

Suddenly, the startup ecosystem is plagued by selective amnesia. It’s embracing the facile, reductionist narrative that cheap money justifies leaders spending recklessly.

And hardly anybody is questioning it.

Let's be clear. The type of waste we've witnessed at tech startups for the past 15 years absolutely could not have occurred without cheap money. But cheap money in and of itself is not dangerous. Leaders who take more of it than they need and spend it irresponsibly? They're dangerous.

I've done so much work in the startup ecosystem over the zero interest period. Some of the startups were super lean. They kept expenses low. They only grew when it made sense. They pushed back on receiving big checks. Some of them didn't. Some of them took big checks because VCs insisted or simply because it was too tempting. Then, they had to find ways to justify the spend. So they overhired and over engineered. Over, and over, and over...

Of course, it's largely the startup owners and operators in that latter group who are now ‘educating’ the masses on zero interest rate phenomena. But maybe if there's anything we've learned here, it’s that austerity should be how startups work by default. Not only when interest rates are above zero.

There’s just one problem. Complexity is seductive.

Watch for tips on how to avoid the trap.

“The farther back you look, the farther forward you see,”

… said Winston Churchill, regarding enterprise technology.

Okay, okay, maybe his mind was in other places.

All joking aside, in the past few days I’ve outlined four major predictions that I believe will hold true for enterprise tech in the next few years, beginning here in 2024:

#1: I believe we are witnessing an inflection point in a shift back towards closed-source or more commercialized software.

#2: Generative AI ‘backbone’ providers - the ones training super intelligent foundation models at scale today - will profit immensely for a long time to come. But these providers are a new piece of our supply chain - not where the value in it terminates.

#3: Voice technology is about to make a significant comeback, finally making its way into the enterprise. Domain-specific products aren't going anywhere. But the way we engage with them will change dramatically.

#4: The way sales-led enterprise SaaS is priced is due for a huge shake-up. We will likely see more varied distribution in pricing models, with a significant uptick in outcome-based pricing.

Many folks in the modern workforce can barely recall a time when enterprise software wasn’t charged for by the seat, on a recurring monthly basis. When that software evolved into SaaS and revenue models turned increasingly recurring, enterprises slowly but surely embraced the shift.

However, the economic and technological ecosystem surrounding enterprise SaaS — especially of the sales-led variety — is changing. For this reason, the time-tested model that has enterprises paying more and more, every year, in perpetuity, is falling out of favor. Slowly, up until now, but soon, all at once.

What’s driving this?

Inflationary environment

For the past year or so, organizations of all shapes and sizes have been far more vigilant about their expenses. CFOs are under constant pressure to optimize budgets, and recurring costs are an obvious target for scrutiny. In particular, high-dollar vendors, especially those whose products are not essential, are facing increased examination. Sales-led enterprise SaaS products, which often come with hefty price tags, are prime candidates for cost-cutting measures.

The question many CFOs are asking is whether these expensive subscriptions are truly indispensable or if more cost-effective alternatives are available. Even for the indispensable vendors, net-dollar retention is down; customers are, with relative ease, negotiating prices back into their favor.

Product-Led Growth

A newer wave of enterprise SaaS companies is shifting the market dynamics. These companies are focusing on user experience and seamless onboarding, adopting a product-led growth strategy. Unlike the traditional sales-led approach, product-led growth allows users to try software without significant upfront commitments. Companies like Attio are meaningfully challenging giants like Salesforce by offering intuitive, user-friendly solutions that don't require extensive sales pitches or long-term contracts. And at a fraction of the price, to boot. This democratizes software access, enabling enterprises to test and decide based on actual usage rather than sales promises.

Artificial Intelligence

AI — in particular the advent of the Large Language Model — is throwing another wrench in the gears. Historically, enterprise SaaS companies enjoyed predictably high margins. This was due to relatively low incremental costs after initial R&D and infrastructure investments. However, AI introduces unit costs previously unimaginable in the SaaS space.

While enterprises are eager to leverage LLMs, pricing these capabilities within the existing SaaS model is challenging. Some companies are significantly raising per-user prices for AI features, but resistance is growing. After all, if net dollar retention is already a problem, how is charging significantly more per seat the solution? This friction indicates that the market is ripe for a pricing model overhaul.

Enter lower-risk and outcome-based alternatives

Many enterprise SaaS companies are already experimenting with alternative pricing models. For example, 37signals, known for their pioneering SaaS products like Basecamp, have recently introduced a one-time payment model after 20 years of subscriptions. This has been met with a tremendous amount of enthusiasm. Meanwhile, transactional pricing models are gaining steam outside of the traditional FinTech use case. For example, Intercom, a leading customer service solution, has an AI-driven add-on named Fin, which they charge for based on the number of customer questions resolvedrather than a flat per-seat fee. This performance-based pricing aligns costs more closely with usage and value delivered, offering a more transparent and fair approach.

Everything in perspective…

Sales-led SaaS companies are not inherently trying to disadvantage their customers. On the contrary, their model has been extremely successful, creating mutually beneficial outcomes for vendors and customers for years. However, as the power balance has tilted slowly over time, customers have become more dissatisfied. Now, combined with more recent shifts in the broader economic and technical ecosystem, it’s clear the winds of change are blowing. I believe they’ll take us to a place that holds a more balanced blend of product-led growth strategies, performance-based pricing, and innovative transaction models that better align with customer needs and technological advancements.

Aside from a shift in medium — from on-premise to the cloud — enterprise software has looked very similar for about 50 years. Row-level data is experienced via one of a few UIs — sometimes tables, sometimes cards, sometimes lists. Aggregate data is available as reports and dashboards — all built using complicated filtering UIs. There are usually different views or portals for different user types. We all know the drill.

Enter voice

Now, I believe that voice technology — last decade, relegated to limited personal capabilities like setting timers and providing weather updates — is about to make a significant comeback. Advancements in natural language processing and machine learning have drastically improved the capabilities of voice technology. And when paired with highly capable large language models such as GPT-X, that voice technology can engage users in highly meaningful conversations.

Insofar as enterprise applications are concerned, this means that AI-powered voice assistants will soon become integral participants in business meetings and daily operations. Imagine an AI ‘colleague’ who can actively listen, comprehend complex discussions, and provide valuable insights or data on the fly. The first point or two on that list are already checked off by tools like Zoom AI, Otter, etc. But the next wave won’t be passive — merely there for listening and summarizing. The next wave will have a metaphorical 'seat at the table', contributing information, assisting in decisions, and even executing basic workflows on the fly.

An important interface, but not the whole product

While voice technology will become more prevalent, it's important to note that voice is merely a mode of conversation, which in turn is one of many types of ‘interfaces’. In the virtual world, a conversation is a way to interact with a domain-specific product. A conversation alone, is not a product.

Consider a sales meeting scenario where a team needs immediate access to performance metrics. Instead of manually navigating through Salesforce or another CRM, a team member might simply ask, "What was our magic number last quarter?" The AI, seamlessly integrated with the CRM, would quickly retrieve the data and provide an answer.

This interaction demonstrates the power of voice as an interface: it’s intuitive and accessible.

Rather than replacing complex systems like a CRM, voice technology will complement them. The CRM will be the engine, and the voice interface will be the ride.

Enterprise software is dead. Long live enterprise software.

Domain-specific products aren't going anywhere. But the way we engage with them will change dramatically.

Verbal conversations with colleagues are high-bandwidth, high-value, and able to be used in many situations where screens and text chats cannot. Everybody intuitively understands this, which is why so much time is spent conversing verbally, even in an increasingly digital world. So it only follows that verbal conversations with our products will become as ubiquitous in the workplace as those with human colleagues.

Generative AI is transforming our work, and a surge of interest and investment in the technology is occurring as a result. Some hypothesize that the large AI companies themselves will own the value that AI creates because of the moats and end user appeal they have been able to manifest so far.

I’m here to make a different case. I believe strongly that history demonstrates a consistent migration of value away from early platforms and towards the end user — in short, applications always prevail.

AT&T

Let’s take a trip back to the early 20th century. The deployment of telephony infrastructure required massive investments. AT&T (then Bell) spent nearly $2.4 billion (equivalent to roughly $50 billion today) on building out physical infrastructure.

Despite these enormous investments, the real financial gains were realized by businesses that used the telephone network to create new services and efficiencies. Industries such as finance, retail, and logistics saw their productivity soar. ROI on the infrastructure itself paled in comparison.

Of course, the infrastructure itself might have done better if AT&T weren’t mandated by the government to break up. This is a bit of a hypothetical, though; The breakup occurred precisely because the government knew AT&T had become too powerful and that more economic value existed on the other side of the breakup.

CompuServe, AOL

When CompuServe and AOL came into the picture in the 90s, dial-up internet was popularized because of how affordable and easy it became to access. Many viewed the internet as these companies and the companies as the internet. However, the real value explosion occurred not within these access services, but as a result of them. The value was on the web.

The web

The web itself was infrastructure — a platform for content and services. Attention shifted to browsers, like Netscape (later Firefox). It became “obvious” to most that if the web was where value was accumulating, then the programs that allowed computers to access it would reign supreme.

While it’s true that browsers did - and still do - provide a lot of power to the companies who maintain them, it is ultimately not where most power or value accumulated. That would be…

The use cases: eCommerce, Software as a Service, etc

Last year, global e-commerce sales reached $5.8 trillion. Trillion.

Meanwhile, the global SaaS market reached $261 billion - a measly number in comparison… until you think about the fact that all of the major telecom providers combined earned roughly the same amount, and with far less operating margin.

From Amazon to Salesforce, so much of the significant value - and profit - exists in the application of technology, not the technology itself.

But Anthony, it’s different this time.

Look, I get it. Training high quality generative AI requires a massive amount of compute infrastructure, yes. But it also requires a massive amount of training data. Neither of these things seem likely to be democratized any time soon.

There’s also an ongoing debate over whether or not a conversational interface is the application. In other words, if a company like OpenAI is both the infrastructure (the GPT-X AI model) and the application (ChatGPT), is there even room for applications ‘on top’?

While the above arguments are rational, I believe vehemently that history will repeat itself. After all, nearly every groundbreaking platform started off as both a piece of infrastructure and a “hello world” application to get people hooked:

• Bell sold both the telephone service and the telephones themselves

• CompuServe and AOL sold both internet access and an application for consumption and conversation

• Netscape and Internet Explorer provided both web access and much of the ‘starting page’ content and tooling at the time

Despite what seemed at the time as inevitable monopolies over both infrastructure and applications, nothing of the sort occurred in the long-run. Instead, all of these companies and products were largely commoditized in favor of more competitive and compelling applications built on top of them.

It’s exactly the same.

Let’s review…

✅ General, generative AI is smart.
✅ Conversational applications are appealing in certain cases.
✅ Data moats are real.

And yet…

✅ Domain-specific and/or private knowledge layered into that is many times more valuable.
✅ New data is more valuable than old data, and requires ever-evolving mouse traps to capture.
✅ Most “human-computer interactions” are really not best had in the form of an open-ended conversation.

And so, ultimately, hype dies down. Moats shift. Sometimes, regulators step in. And most importantly, the real use cases worth paying for prevail, because markets always come out in favor of proven revenue and operating margin, not hypotheticals.

Generative AI ‘backbone’ providers - the ones training super intelligent foundation models at scale today - will profit immensely for a long time to come, no doubt. But make no mistake. These providers are a new piece of our supply chain - not where the value in it terminates.

99+% of enterprise software utilizes open source technology — typically at minimum hundreds of packages. However, the open-source software ecosystem is facing unprecedented challenges that threaten its very foundation.

It is my belief that we are witnessing an inflection point in a shift back towards closed-source or more commercialized models, particularly in the realm of web-based technologies. Here’s why:

1. Security is at a breaking point

It is becoming increasingly difficult on the consuming side of open source to ensure its security. While this challenge has been growing over time, it is underscored of late by the sophisticated and novel attack on XZ Utils, a popular set of data compression tools used in major Linux distributions. In early 2024, a pseudonymous attacker introduced a backdoor into XZ Utils, leading to significant disruptions, including delaying a release of Ubuntu, the most popular Linux variant in circulation. This exploit was part of a larger social engineering campaign targeting open source maintainers through fake identities and urgent requests for maintainer access. Perhaps most concerning is that by all accounts, fairly extensive security research never identified the backdoor. Rather, it was identified by one individual through pure luck.

When utilizing commercialized technology, the process is primarily designed around trusting both the third party vendor and that vendor’s SDLC. But is it even possible for the open source ecosystem to cohesively rally around the idea of a maintainer model that is more transparent and that allows open source consumers to vet the maintainers the same way they do third party vendors? What about governance over SDLCs? And what about at the magnitude of hundreds or thousands of separate maintainers?

2. Licensing is tenuous

For nearly a decade, there has been a gradual shift in licensing trends from permissive licenses like MIT to more restrictive ones. This trend gained significant momentum around 2018 during Redis’s and MongoDB’s feud with AWS, resulting in those projects adopting licenses that limit commercial exploitation.

More recently, the predominant Infrastructure-as-Code tool, HashiCorp’s Terraform, also changed its license. The community responded with a “hard forked” version named OpenTofu. Shortly thereafter, OpenTufu was soon issued a cease-and-desist by Hashicorp.

Throughout battles like these, all open-source consumers can do is choose between multiple evils and hope for the best. It’s ugly.

3. The funding model is broken

Despite widespread use, funding for open-source projects has not kept pace with their growing volume and importance. Many projects rely on the goodwill of contributors and sporadic donations. The projects not in this boat are often backed by large commercial entities - many of which are eventually tempted to swap licensing models.

Take OpenSSL, which is utilized by virtually every enterprise SaaS vendor in some form to encrypt communications, yet only received substantial funding after the Heartbleed vulnerability in 2014 exposed critical security flaws.

4. The regulatory landscape has shifted

Recent federal mandates on Software Bill of Materials (SBOMs) have placed additional pressures on consumers of open-source software. This means that virtually overnight, enterprise SaaS vendors are being required to provide detailed information on all of the software components in their products, including version numbers. This level of rigor was only previously required for “subprocessors” - typically defined as third-party commercial vendors. Of course, there are much fewer of these in the typical SaaS offering than there are open source packages. Commercial dependencies are much easier to inventory, and more concerning, much easier to govern.

These factors are all, increasingly, contributing to a certain type of paralysis when it comes to the use of open source software in enterprise SaaS products. And as a result, it seems to me that the flexibility and communal spirit that helped make open source the behemoth it is today is becoming a very distant memory.

It is for these reasons that I believe the industry will likely see a pivot back towards more controlled and commercial software consumption. Of course, much like today’s landscape, this will not be an all-or-nothing affair. It will be observable on a spectrum, measured in shifting preferences and percentages. But watch this spectrum closely. There will be big winners, big losers, and a lot of innocent bystanders as a result.

For anyone managing a SaaS platform, cloud costs can often feel like a sizable and unpredictable utility bill that shows up at the end of the month. I’ve seen them leave finance teams in absolute shock. What’s the path forward?

CapEx → OpEx & COGS

Transitioning from server farms (CapEx) to cloud services (OpEx and COGS) over the past ~15 years has fundamentally changed how businesses think about spending on compute. While traditional servers represented a fixed, upfront investment, cloud services are more like renting an apartment — with ongoing costs that get counted directly against operations or goods sold.

Typical SaaS companies find around 5-10% of their ARR flowing into cloud expenses. In my own experience across various SaaS orgs, it’s been in the 6-8% range.

On the bill itself, it’s common to find that 25-50% of it is spent on OpEx (e.g. Telemetry tools that help monitor and triage system issues), with the rest primarily representing COGS (e.g. compute needed to keep an application running for a set of customers).

Strategies to reduce your fixed costs

Effectively managing cloud costs is a balancing act between flexibility and monetary restraint. These are the common strategies for reducing costs related to the amount of cloud resources you tend to use, at minimum, every month:

1. Cost savings plans
   This strategy is typically low effort, low risk, and high reward.
   Many cloud providers offer flexible cost savings plans for server instances that provide significant discounts in exchange for commitment to a certain level of spending. These plans are a smart move for businesses with predictable usage patterns around their server instances as they allow access to lower rates while retaining a great deal of flexibility. However, be warned - if there’s a chance you might need to significantly reduce your cloud spend soon, committing to a high spend might trap you into an expensive arrangement.

2. Reservations
   This strategy is typically moderate effort, moderate risk, and high reward.
   For companies with stable and predictable long-term needs, committing to reserved server instances can yield higher discounts compared to flexible savings plans. While this strategy locks you into specific types of server instances - as opposed to savings plans which provide more flexibility over time - the cost benefits are more substantial. This strategy is best suited for mature organizations that have clear visibility into their future requirements.

3. Consolidation of systems
   This strategy is typically high effort, low risk, and high reward.
   By optimizing resource usage through techniques such as “bin packing” and implementing multi-tenancy architectures, you can significantly reduce wasted capacity and improve overall efficiency. This approach not only maximizes the utilization of existing resources but also decreases the need for additional spending on underutilized services.

4. Enterprise Discount Plans (EDPs)
   This strategy is typically moderate effort, moderate risk, and moderate reward.
   EDPs are tailored to rapidly growing startups and offer discounts based on anticipated growth in cloud service usage. While they can provide substantial cost savings for businesses in a high-growth phase, they also come with the risk of locking you into higher future spending. It can’t be understated how important it is to carefully project future usage to avoid overcommitment here.

5. Resellers and Arbitrage
   This strategy is typically moderate effort, moderate risk, and moderate reward.
   Engaging with resellers who buy cloud resources in bulk and then pass on the savings to their customers can be another avenue to reduce costs. These players leverage enterprise discount plans and other mechanisms to offer services at reduced rates. However, the effectiveness of this strategy can vary, and sometimes the administrative and support complexities might not justify the potential savings.

The variability dilemma

Once we move past the fixed costs, it becomes clear that there can be significant variability in monthly bills as well. I’ve seen orgs range from 10-30% variable cost per month. How to reason about it?

This variability - usually driven by some combination of auto-scaling, redundant system deployments for upgrades and migrations, and R&D - is a double-edged sword. On one hand, it allows flexibility for the infrastructure team and promotes reliability for customers. On the other, it can spiral into wasteful spending if not monitored closely.

Here’s where waste usually sneaks in:

1. “Permanent temporaries”: Resources intended for short-term use may linger longer than necessary, inadvertently inflating costs. Whether it’s infrastructure left running after delayed updates or R&D tools unused during project pauses, each scenario begs the question: Is it cheaper to leave it running until needed again or rebuild it at that time? What is the cost of your employees’ time?

2. Maintenance lapses: Often, there’s no dedicated team managing these costs full-time, leading to suboptimal cost management practices.

Strategies for dealing with variability

To combat these challenges and avoid poor cloud hygiene, consider the following:

1. Detailed tagging: It’s crucial to map costs back to specific vectors of spend - region, tenancy, environment, initiative, product line, etc. Cloud platforms allow for this type of tagging, but it requires some additional tooling and discipline to get right, especially for containerized resources. This is the biggest effort you will undertake in dealing with variability, but it’s your only shot at getting this right. Just do it.

2. Tag probable waste: The first time you ever do this, create a tag that indicates likely waste. This way, when you’re done inventorying your system, you can narrow in on what is likely to be waste, make decisions quickly, and get your bill back in shape.

3. Regular audits: Have your infrastructure team conduct weekly “glances” at and monthly reviews of cloud expenditures.

4. Proactive ticket management: Ask that infrastructure teams include potential cost implications in their ticket workflows, this way costs can be predicted to the extent possible, and otherwise investigated if a spike pops up. Note that you’re not looking for perfection here; There is a cost to estimation precision, too. You’re just looking for a basic level of diligence.

5. An accountable party: Assign someone the task of tracking and reporting on potential future anomalies and actual anomalies from the recent past. Remember, not all anomalies are a function of waste! The point of this role is not to eliminate anomalies, but rather to a) help better model them and b) help more quickly catch and remediate them when proven to be wasteful.

Go forward

While cloud costs are indeed variable and difficult to model with ultra-precision - similar to a utility bill - it is in fact possible for a SaaS organization to gets its arms around the scope of potential variability in play, and react quite quickly if and when that fails. Investing even a small amount into process, tooling, and a cultural acceptance of the balance between ‘good’ and ‘bad’ variability will go a long way.

The only responsible way to upgrade technology is slowly and methodically. And in the meantime, risk mitigation is the name of the game.

Digging in

Mature technology companies tend to upgrade their stacks like so:

This is called the strangler fig pattern. It is methodical. It is consistent. It is reliable. It is often slow. So very slow.

Oh, and one more thing. There’s often no real “finish” line.

Let’s compare to the real world

Houses are typically renovated piece by piece, room by room - new strangling out old over years. Some rooms or foundational infrastructure remain original regardless. And whatever code they were built to at that original time is grandfathered in.

This 3-mile-long boardwalk at a beach town near my house has been getting strangled by a new boardwalk, block by block, for nearly a decade.

What have we learned?

These types of upgrade projects often take much longer than the initial construction. And note how they are so piecemeal that old infrastructure is never totally eradicated; By the time everything is new, something is old again. The old and new must find a way to coexist in harmony.

What about the risk inherent in the old technology?

From a delivery efficiency and security perspective, this risk of legacy technology is often dealt with by monitoring and managing pointed, known risks, then mitigating them to the best extent possible. Returning to the boardwalk example, if one plank in particular is so degraded that it represents an outsized danger to pedestrians, that one plank can be replaced.

The digital world is no different than the real world in this regard. Remember to be pragmatic and patient out there!

Generative AI is the next big thing for your established B2B SaaS company and it’s going to be so easy. Slap some OpenAI API calls into your existing product and ship. Right?

Well, it’ll be a fun prototype.

However, successful production integration of GenAI is the culmination of systematic team training and the careful crafting of intelligent, context-aware interactions that enhance user experiences without compromising on quality or ethics. Moreover, ongoing maintenance to train and refine the GenAI models is critical to adapt to evolving data and user feedback.

Simply put, GenAI isn’t a plug-and-play solution; it’s a process, and it’s a commitment.

The framework

Because established B2B SaaS companies cannot implement and succeed with GenAI overnight, I am advising them to follow a framework that focuses on:

• A slow buildup of a moat

• Keeping risk in check

• Proper education for internal and external stakeholders

• Predicting and tracking regulation

• The inherent complexity in balancing all of this appropriately

The idea is that you don’t want your company to move too quickly or too slowly. It should be innovating, but responsibly.

From this, 3 phases emerge:

Phase 1: The foundation

3-6 months

In the initial phase, I recommend investing in three distinct areas and manners:

• Training your team on the basics: Your team will need time to learn the basics. And let’s face it — You do not want your team releasing high-impact, high-security use cases until they are truly ready.

• Foundation models with public data and a human in the middle: Now is not the time to fine tune models based on massive amounts of your customers’ data. That will come. For now, simply integrate GenAI capabilities that are available outside of your product already, into your product. Also ensure the use cases you develop always keep a human in the loop. Think: Allowing a customer to summarize a single file interactively based on a public foundation model like GPT-4.

• Community thought leadership: Make sure customers know what types of use cases your company will explore in the future, how to help get their data ready for that future, and what to generally expect once everybody arrives.

Phase 2: The leverage

6-12 months

In this second phase, invest in:

• Training those interested in becoming experts: Once a significant portion of your team is proficient with GenAI, ensure that a subset of folks from here become experts. From advanced prompt engineering to fine tuning, and controlling for security concerns to understanding the regulatory environment, there is a lot to learn. To work towards a moat, you need these capabilities in-house.

• Low-risk use cases that utilize fine-tuning, embeddings, and other advanced techniques based on individual customer data: Build upon your team’s “text book” and real world knowledge of the journey so far to begin delivering on use cases that are more proprietary to your business. Note, here, that it is still important to ensure the GenAI that your product offers is transparent and keeps a human in the loop. Think: An assistant that answers questions for an individual customer about that same customer’s data.

• Advanced community thought leadership: Customers should understand that there is a shared responsibility model when it comes to the safe and responsible usage of AI. Ensure they know what you consider your responsibility to be vs. where they need to invest in their own training and policies.

Phase 3: The moat

As you enter the third phase, it’s all about leveraging your organization’s breadth of data along with the capabilities refined above to drive value that your competitors simply cannot touch.

Here, invest in:

• Use cases that leverage advanced techniques based on data about your entire customer base: Think: Intelligent search within your product based on knowledge of the customer base’s domain.

• Moderate-to-higher risk use cases: This may include cases where important decisions are being made, and there is the potential for GenAI to be relied on too heavily in making them. In my view, this is acceptable as long as implemented carefully, and as long as it’s clear to customers what their responsibilities are. Think: Features that allow customers to classify records they have in their database based on your company’s unique knowledge of the customer base’s domain and other similar data.

• Community engagement: More than just ‘thought leadership’, true engagement with your community to ensure that as the GenAI capabilities in your product grow, your customers understand its limits and how to use it responsibly. You will iterate and refine your product based on this.

The journey

Your product wasn’t created overnight and neither will its GenAI capabilities - especially if you want them to become a moat. Embracing generative AI means embracing a phased, methodical journey. This will set both you and your customers up for long-term success.