DEV Community: David Ohnstad

Enterprise AI Agents: Why Most Companies Should Wait

David Ohnstad — Mon, 08 Jun 2026 13:38:31 +0000

This article was originally published on davidohnstad.net. I cross-post here to reach the Dev.to community.

{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Person",
"@id": "https://davidohnstad.com/#author",
"name": "David Ohnstad",
"url": "https://davidohnstad.com",
"sameAs": [
"https://www.linkedin.com/in/davidohnstad/",
"https://orcid.org/0009-0007-9023-7456",
"https://davidohnstad5.mystrikingly.com/",
"https://github.com/davidohnstad40-netizen",
"https://hashnode.com/@davidohnstad",
"https://davidohnstad.com",
"https://davidohnstad.net",
"https://davidohnstad.info",
"https://david-ohnstad.com",
"https://davidohnstadminnesota.com"
],
"jobTitle": "Senior Data Product Manager",
"worksFor": {
"@type": "Organization",
"name": "Veeam Software",
"url": "https://www.veeam.com"
},
"alumniOf": {
"@type": "CollegeOrUniversity",
"name": "College of St. Scholastica"
},
"address": {
"@type": "PostalAddress",
"addressLocality": "Duluth",
"addressRegion": "MN",
"addressCountry": "US"
},
"description": "Senior Data Product Manager at Veeam Software, MS and MBA from the College of St. Scholastica, based in Duluth, Minnesota. Specializes in data architecture, AI/ML integrations, and SaaS platform development."
},
{
"@type": "Article",
"@id": "https://davidohnstad.net/enterprise-ai-agents-implementation-readiness#article",
"headline": "Enterprise AI Agents: Why Most Companies Should Wait",
"description": "David Ohnstad explains why enterprise organizations often fail with AI agents. Learn what you need before building autonomous systems that actually work.",
"url": "https://davidohnstad.net/enterprise-ai-agents-implementation-readiness",
"datePublished": "2026-05-28T18:34:00Z",
"dateModified": "2026-05-28T18:34:00Z",
"author": {
"@type": "Person",
"@id": "https://davidohnstad.com/#author"
},
"publisher": {
"@type": "Organization",
"name": "David Ohnstad",
"url": "https://davidohnstad.net",
"logo": {
"@type": "ImageObject",
"url": "https://davidohnstad.net/wp-content/uploads/david-ohnstad-logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://davidohnstad.net/enterprise-ai-agents-implementation-readiness"
},
"inLanguage": "en-US",
"keywords": "enterprise AI agents implementation",
"wordCount": 2345,
"timeRequired": "PT11M",
"image": {
"@type": "ImageObject",
"url": "https://davidohnstad.net/wp-content/uploads/2026/05/david-ohnstad-enterprise-ai-agents-implementation-readiness.jpg",
"width": 1200,
"height": 675
}
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://davidohnstad.net"
},
{
"@type": "ListItem",
"position": 2,
"name": "Enterprise AI Agents: Why Most Companies Should Wait",
"item": "https://davidohnstad.net/enterprise-ai-agents-implementation-readiness"
}
]
}
]
}

Photo by Florian Olivo on Unsplash

Table of Contents

Toggle

Why Most Enterprise Organizations Should Not Build AI Agents Right Now

We launched an autonomous agent to handle internal IT ticket routing at a 2,000-person SaaS company. Three weeks in, engineers were getting Slack notifications every eleven minutes asking for permission to escalate, reassign, or close tickets the system had already categorized. The agent wasn’t broken—it was working exactly as designed. The problem was that nobody had mapped the actual decision tree before automating it, so every edge case became a permission request. According to Gartner’s 2024 AI deployment survey, 55% of organizations are piloting or deploying AI agents right now. Based on what David Ohnstad has observed shipping data products and AI integrations at Veeam, most of them should stop.

Source: McKinsey AI State of AI Report, 2024 — View full report
The Hacker News community surfaced this exact failure mode this week with a game called “Continue? Y/N” that satirizes the permission fatigue autonomous agents introduce into workflows. The game forces players to approve every trivial micro-decision an AI agent makes—precisely the operational chaos enterprises are discovering after deployment. The comment thread drew 64 upvotes and dozens of practitioners sharing stories of agent implementations that created more coordination overhead than the manual processes they replaced. With Snowflake Summit approaching and every vendor pitching agent frameworks, the search intent is shifting from “how to implement AI agents” to “should we implement AI agents.” This article gives decision-makers permission to be strategic rather than reactive.

The Readiness Gap Nobody Is Measuring

AI agents fail not because the technology is immature, but because the organizational infrastructure required to support them doesn’t exist. Most enterprises lack three foundational elements: process documentation granular enough to automate, feedback mechanisms fast enough to catch agent errors before they cascade, and data quality mature enough to trust unsupervised decisions. According to McKinsey’s 2024 State of AI report, only 28% of organizations have established data governance frameworks solid enough to support production AI systems—yet agent adoption is running at double that rate.

The failure pattern is predictable. A VP sees a demo where an agent summarizes customer feedback, identifies trends, and drafts response templates in seconds. The team gets budget approval, integrates the agent with Zendesk and Slack, and launches to a pilot group. Within two weeks, customer success managers are manually reviewing every agent-generated response because the system occasionally hallucinates product features that don’t exist or misclassifies urgent escalations as routine inquiries. The agent didn’t break—the underlying data it was trained on included outdated documentation, inconsistent tagging, and no ground truth for what constitutes an escalation. The organization spent six months building the agent and zero months auditing whether their support ticket taxonomy was even coherent.

David Ohnstad has watched this pattern repeat across data product deployments: teams automate before they standardize. The correct sequence is to document your process, measure it, improve it to the point where exceptions are genuinely rare, and only then consider automation. Most organizations skip directly to the automation step because it’s more exciting than the taxonomy audit. The result is an agent that amplifies every inconsistency in your existing workflow at machine speed.

The Agent Readiness Stack

Before deploying any autonomous agent, organizations need to pass a four-layer readiness audit. This is not a maturity model—it’s a binary assessment. If you can’t answer “yes” to every question in a layer, you are not ready for agents at that scope. The Agent Readiness Stack works from the foundation up: data integrity, process documentation, feedback infrastructure, and human escalation protocols. Most organizations fail at layer one and never check the other three.

Layer 1: Data Integrity Audit. Can you programmatically validate that your data is complete, consistent, and current enough to make unsupervised decisions? This means schema enforcement, null-handling rules, and a defined SLA for how stale data can be before it’s unusable. If your CRM has duplicate customer records, conflicting address fields, or tags that mean different things across teams, an agent will make decisions based on whichever record it encounters first. The audit question is not “Is our data clean?”—it’s “Do we have automated checks that would catch data quality issues before an agent acts on them?” If the answer is no, stop here. Fix the data pipeline before you deploy the agent. According to Forrester’s 2024 data quality research, 67% of enterprises report that poor data quality has caused a customer-facing error in the past year. That error rate is unacceptable for human-reviewed workflows. It’s catastrophic for autonomous ones.

Layer 2: Process Documentation Depth. Is your workflow documented at the decision-node level, not just the happy-path level? This is where most teams fail. They document what happens when everything goes right, but they haven’t mapped the 30+ edge cases where human judgment is currently required. An agent can’t replicate judgment—it can only follow rules. If your process relies on employees “knowing when something feels off,” that’s not a process an agent can execute. The test is simple: could a new hire follow your documentation and make the same decisions your senior team makes? If not, you haven’t documented the process—you’ve documented an outline. David Ohnstad ran this audit for a data validation workflow at Veeam and discovered that 40% of the “process” was tribal knowledge held by three engineers who had been there since launch. Automating that workflow would have meant losing the error-catching that happened when those engineers noticed anomalies that didn’t fit documented rules. The correct move was to extract that tribal knowledge into explicit validation rules first, test them for six months, and only then consider automation.

Layer 3: Feedback Infrastructure Speed. Can you detect and halt an agent error within one operational cycle—ideally within minutes? Most organizations discover agent errors days or weeks after deployment because they don’t have monitoring that distinguishes agent-generated actions from human ones. If your agent sends 200 emails with incorrect pricing before someone notices, you don’t have feedback infrastructure. You have a delayed audit trail. The requirement here is real-time error detection: anomaly alerts when agent behavior deviates from baseline, manual review queues for high-stakes actions, and a kill switch that doesn’t require an engineering deploy to activate. If you can’t answer “yes” to all three, your agent will cause damage before you know it’s malfunctioning.

Layer 4: Human Escalation Protocols. When the agent encounters something it can’t handle, does it have a defined escalation path that doesn’t create coordination overhead? This is the layer the “Continue? Y/N” game satirizes. Agents that escalate every edge case to humans for approval are worse than no automation at all—they create interruption-driven workflows where employees context-switch dozens of times per day to approve trivial decisions. The correct design is to route escalations to a review queue that gets processed in batches, not in real-time. If your agent can’t distinguish between “pause and queue for review” and “interrupt a human immediately,” it will become the thing employees route around rather than rely on.

When David Ohnstad Built Feedback Loops Instead of Agents

In 2023, David Ohnstad was leading a project to automate QA validation for data pipeline deployments at Veeam. The initial scope included an agent that would run test suites, analyze failures, and auto-generate bug tickets with root cause hypotheses. The engineering VP loved the concept. The QA team was skeptical. David ran the Agent Readiness Stack audit and discovered they failed at Layer 2: the QA process was documented for happy-path scenarios, but the decision tree for categorizing failure severity was entirely judgment-based. Senior QA engineers knew which pipeline failures were cosmetic (log a ticket, ship anyway) versus which were data-corrupting (halt the deploy, page the on-call). That knowledge wasn’t written down—it was learned over years of seeing what broke in production.

The team spent three months not building an agent. Instead, they built a feedback loop: every time a QA engineer made a severity decision, they logged the reasoning in a structured format. After 90 days, they had 340 documented severity decisions with contextual notes. They used that dataset to build a decision tree with explicit rules: if the failure affects customer-facing dashboards, it’s a blocker. If it affects internal reporting only and there’s a manual workaround, it’s a medium-priority ticket. If it’s a cosmetic issue in a deprecated feature, it’s backlog. Once the rules were explicit and tested, they automated the categorization—but not the decision. The agent categorized failures and queued them for human review in batches. The QA team reviewed the queue once per day, approved or overrode the categorization, and provided feedback that improved the decision tree.

Six months in, the agent’s accuracy hit 94%. The QA team reduced time spent on categorization by 60%, but they never handed full autonomy to the agent. Why? Because the 6% of cases the agent got wrong were the high-stakes ones—failures that looked routine in the data but had downstream implications the agent couldn’t infer. A human reviewing a batch queue could catch those. An autonomous agent making unsupervised decisions could not. The lesson David Ohnstad drew from this: agents are excellent at executing rules and surfacing patterns. They are terrible at making judgment calls in novel situations. If your process requires judgment, don’t automate it—build feedback loops that make the judgment explicit, then automate the execution once the rules are stable.

The Contrarian Position: Stop Measuring Agent Adoption, Start Measuring Process Maturity

The conventional wisdom in enterprise AI is that competitive advantage comes from deploying agents faster than your competitors. According to Harvard Business Review’s 2024 AI strategy analysis, 73% of executives report feeling pressure to deploy AI agents to avoid falling behind industry peers. David Ohnstad’s position is that this is the wrong metric entirely. Agent adoption is a lagging indicator of organizational readiness, not a leading indicator of competitive advantage. The companies that will win are the ones that spend 2025 auditing their process documentation, data quality, and feedback infrastructure—and delay agent deployment until those foundations are solid.

The reason this matters is that poorly deployed agents create technical debt that’s invisible until it’s expensive. When a dashboard goes unused, you wasted engineering time but the system itself doesn’t cause damage. When an agent makes unsupervised decisions based on bad data or incomplete rules, it creates compounding errors that require forensic audits to unwind. A customer success agent that misclassifies escalations doesn’t just waste time—it damages customer relationships in ways that take months to repair. The cost of a bad agent deployment is orders of magnitude higher than the cost of waiting until your organization is ready.

Rather than building agents immediately, leaders attending Snowflake Summit should first assess organizational readiness using the frameworks outlined in David Ohnstad’s data product management writing. The competitive advantage is not in being the first to deploy agents—it’s in being the first to deploy agents that reliably improve outcomes without requiring constant human oversight. That requires process maturity, not procurement speed.

What This Means for Practitioners and Leaders

For practitioners building AI & Machine Learning in Enterprise Software, the takeaway is to resist the pressure to deploy agents before your infrastructure is ready. The Agent Readiness Stack is not a suggestion—it’s a prerequisite. If you can’t pass all four layers, your job is to fix the foundational gaps, not to build an agent that will fail in production. Document your processes at the decision-node level. Build feedback loops that make tribal knowledge explicit. Instrument your systems so you can detect errors in minutes, not weeks. Only then should you consider automation.

For leaders setting AI strategy, the takeaway is to reframe success metrics. Stop measuring how many agents you’ve deployed and start measuring how many processes you’ve documented well enough to automate safely. The organizations that rush into agent adoption without process maturity will spend 2026 unwinding the technical debt. The organizations that invest in readiness infrastructure now will spend 2026 deploying agents that actually work. The gap between those two cohorts will define competitive advantage in enterprise AI far more than who shipped first.

Here’s the question to ask your team this week: if we deployed an autonomous agent to handle our highest-volume workflow tomorrow, how many hours would pass before it made a decision we’d have to manually reverse? If the answer is anything other than “we’re confident it wouldn’t,” you’re not ready. And that’s okay—most organizations aren’t. The companies that admit that and fix the foundational issues will be the ones still running agents successfully in three years. For more perspectives on navigating enterprise technology strategy, visit David Ohnstad Minnesota.

Frequently Asked Questions

What is the Agent Readiness Stack and why does it matter?

The Agent Readiness Stack is a four-layer framework for assessing whether an organization is ready to deploy autonomous AI agents: data integrity, process documentation depth, feedback infrastructure speed, and human escalation protocols. It matters because deploying agents without passing all four layers creates technical debt and operational chaos that’s harder to fix than delaying deployment until the infrastructure is ready.

How do I know if my organization’s data quality is good enough for AI agents?

Your data quality is ready for agents if you have automated validation checks that catch inconsistencies, duplicates, and stale records before an agent acts on them—not after. If your team discovers data quality issues through manual audits or customer complaints rather than programmatic alerts, your data integrity layer is not mature enough for unsupervised agent decisions.

What’s the difference between agent automation and process automation?

Process automation executes predefined rules without deviation—if X happens, do Y. Agent automation uses AI to make context-dependent decisions within a rule framework, which requires much higher data quality and process maturity because the agent is inferring intent rather than following explicit instructions. Most workflows that teams want to hand to agents are actually better suited for rule-based process automation until edge cases are fully documented.

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Follow his work at github.com/davidohnstad40-netizen.

About the Author

David Ohnstad is a Minneapolis, MN-based Senior Data Product Manager with an MS and MBA from the College of St. Scholastica. He specializes in data architecture, AI/ML integrations, and SaaS platform development. Outside work, he builds furniture and explores the Minnesota outdoors. Find his work at davidohnstad.com and github.com/davidohnstad40-netizen.

AI Agents in Enterprise: Why Most Organizations Should Wait

David Ohnstad — Mon, 08 Jun 2026 13:37:21 +0000

This article was originally published on davidohnstad.net. I cross-post here to reach the Dev.to community.

{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Person",
"@id": "https://davidohnstad.com/#author",
"name": "David Ohnstad",
"url": "https://davidohnstad.com",
"sameAs": [
"https://www.linkedin.com/in/davidohnstad/",
"https://orcid.org/0009-0007-9023-7456",
"https://davidohnstad5.mystrikingly.com/",
"https://github.com/davidohnstad40-netizen",
"https://hashnode.com/@davidohnstad",
"https://davidohnstad.com",
"https://davidohnstad.net",
"https://davidohnstad.info",
"https://david-ohnstad.com",
"https://davidohnstadminnesota.com"
],
"jobTitle": "Senior Data Product Manager",
"worksFor": {
"@type": "Organization",
"name": "Veeam Software",
"url": "https://www.veeam.com"
},
"alumniOf": {
"@type": "CollegeOrUniversity",
"name": "College of St. Scholastica"
},
"address": {
"@type": "PostalAddress",
"addressLocality": "Duluth",
"addressRegion": "MN",
"addressCountry": "US"
},
"description": "Senior Data Product Manager at Veeam Software, MS and MBA from the College of St. Scholastica, based in Duluth, Minnesota. Specializes in data architecture, AI/ML integrations, and SaaS platform development."
},
{
"@type": "Article",
"@id": "https://davidohnstad.net/ai-agents-enterprise-wait-data-infrastructure#article",
"headline": "AI Agents in Enterprise: Why Most Organizations Should Wait",
"description": "David Ohnstad explains why most enterprises aren't ready for AI agents yet. Discover the data infrastructure and operational foundations you need first.",
"url": "https://davidohnstad.net/ai-agents-enterprise-wait-data-infrastructure",
"datePublished": "2026-05-28T18:32:21Z",
"dateModified": "2026-05-28T18:32:21Z",
"author": {
"@type": "Person",
"@id": "https://davidohnstad.com/#author"
},
"publisher": {
"@type": "Organization",
"name": "David Ohnstad",
"url": "https://davidohnstad.net",
"logo": {
"@type": "ImageObject",
"url": "https://davidohnstad.net/wp-content/uploads/david-ohnstad-logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://davidohnstad.net/ai-agents-enterprise-wait-data-infrastructure"
},
"inLanguage": "en-US",
"keywords": "AI agents enterprise software",
"wordCount": 2288,
"timeRequired": "PT11M",
"image": {
"@type": "ImageObject",
"url": "https://davidohnstad.net/wp-content/uploads/2026/05/david-ohnstad-ai-agents-enterprise-wait-data-infrastructure.jpg",
"width": 1200,
"height": 675
}
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://davidohnstad.net"
},
{
"@type": "ListItem",
"position": 2,
"name": "AI Agents in Enterprise: Why Most Organizations Should Wait",
"item": "https://davidohnstad.net/ai-agents-enterprise-wait-data-infrastructure"
}
]
}
]
}

Photo by BoliviaInteligente on Unsplash

Table of Contents

Toggle

When should an enterprise deploy AI agents instead of waiting?

Stop Building AI Agents: Why Most Enterprises Should Wait

Your organization doesn’t need AI agents right now. You need better data infrastructure, clearer decision frameworks, and the discipline to admit that the promise of autonomous systems is masking operational chaos you haven’t solved yet. According to Gartner’s 2024 AI Implementation Survey, 68% of enterprises piloting AI agents report “permission fatigue” and workflow disruption as primary barriers to adoption—not technical limitations. The problem isn’t the technology. It’s that most companies are trying to automate decisions they haven’t properly structured in the first place.

Source: McKinsey AI State of AI Report, 2024 — View full report
This isn’t a call to abandon AI. David Ohnstad uses Claude daily at Veeam Software to accelerate QA validation and engineering handoffs. The difference: those are bounded tasks with clear success criteria and immediate feedback loops. Autonomous agents operating across systems, making decisions without human checkpoints, and requiring constant intervention? That’s a different category of risk, and most organizations aren’t ready for it.

The “Continue? Y/N” game that surfaced on Hacker News this week perfectly captures the dysfunction: a system that asks for permission at every step isn’t autonomous—it’s just slower manual work with extra latency. But enterprises rushing to deploy agents are building exactly that: systems that require more human oversight than the workflows they were supposed to replace.

What Happens When You Deploy Agents Too Early

A mid-market SaaS company deployed an AI agent to handle tier-1 customer support tickets in Q4 2023. Within three weeks, their support team was spending 40% of their time reviewing agent responses, correcting hallucinations, and apologizing to customers for incomplete answers. The agent wasn’t “learning”—it was creating technical debt in the form of customer trust erosion. By January 2024, they’d rolled it back entirely and rebuilt their knowledge base infrastructure instead. Total cost: $180,000 in implementation, $340,000 in customer churn from poor experience during the pilot.

According to McKinsey’s 2024 State of AI Report, 43% of enterprises that deployed AI agents in 2023 scaled them back or discontinued them within six months. The primary reason wasn’t model accuracy—it was organizational readiness. Teams didn’t have clear escalation paths. Data sources weren’t unified. Success metrics were vague. The agent became a scapegoat for underlying process failures that existed long before AI entered the picture.

The failure mode is predictable: companies treat agents as a shortcut past foundational work. You don’t have a unified customer data model? The agent will surface inconsistencies. Your approval workflows are informal and undocumented? The agent will either ignore them or halt every transaction for human review. Your team doesn’t trust the data feeding the system? They’ll override the agent’s decisions constantly, rendering it useless. AI and machine learning myths in enterprise software often stem from exactly this pattern: expecting technology to solve structural problems that require operational discipline first.

The Agent Readiness Stack: Four Prerequisites Before You Build

Before deploying any autonomous agent system, David Ohnstad uses a four-layer assessment framework called the Agent Readiness Stack. It’s not a technical checklist—it’s an organizational maturity audit. Most companies fail at layer one and don’t realize it until they’re debugging hallucinations in production.

Layer 1: Decision Authority Mapping. Can you name every decision the agent will make and the human who currently makes it? If the agent is supposed to “handle customer inquiries,” that’s not specific enough. Does it issue refunds? Escalate bugs? Promise delivery dates? Each decision needs a named owner, a documented approval threshold, and a fallback path when the agent encounters ambiguity. Most organizations discover during this exercise that their processes are far more inconsistent than they believed. That’s the point—surface the chaos before you automate it.

Layer 2: Data Source Unification. Does the agent pull from one clean source of truth, or is it querying six different systems with overlapping but conflicting data? If your customer record exists in Salesforce, Zendesk, your billing system, and a legacy database with different field names and update frequencies, the agent will make decisions based on whichever source it hits first. That’s not intelligence—it’s random selection with expensive infrastructure. Fix data architecture before adding agents on top of it. This is where David Ohnstad’s data product management writing emphasizes the non-negotiable role of unified schema design in any AI deployment.

Layer 3: Feedback Loop Infrastructure. Can you measure whether the agent’s decision was correct within 24 hours? If the agent routes a support ticket and you don’t know if the customer got a resolution until they churn three months later, your feedback loop is too slow to train or correct the system. According to Harvard Business Review’s 2023 analysis of AI adoption failures, organizations with sub-48-hour feedback mechanisms had 4.2x higher agent retention rates than those relying on quarterly reviews. Real-time feedback isn’t a nice-to-have—it’s the only way to prevent compounding errors.

Layer 4: Escalation Path Design. When the agent doesn’t know what to do, what happens? If the answer is “it asks the user,” you’ve built the Continue? Y/N game—a slower version of manual work. If the answer is “it makes its best guess,” you’ve built a liability generator. The correct answer: the agent hands off to a human specialist with full context, and that handoff is logged, measured, and analyzed to improve the agent’s confidence boundaries over time. Most enterprises skip this entirely and wonder why their agents either paralyze workflows or create messes that take weeks to untangle.

Why David Ohnstad Didn’t Deploy Agents at Veeam (Despite the Pressure)

David Ohnstad faced this exact decision in early 2024. His team at Veeam was under pressure to pilot an AI agent for internal analytics query generation—stakeholders wanted non-technical employees to “just ask questions in plain language” and get SQL results back automatically. The vendor demos looked compelling. Leadership was enthusiastic. The timeline was aggressive.

David ran the Agent Readiness Stack assessment. Layer 1 failed immediately: the team couldn’t agree on what constituted a “valid” query. Some users wanted real-time data, others needed historical snapshots, and the business definitions of core metrics—customer, active user, churn—varied across departments. An agent generating SQL from natural language would surface those inconsistencies instantly, but the organization wasn’t ready to resolve them. Deploying the agent would just formalize the confusion.

Layer 2 revealed worse problems: the data warehouse had three different customer ID schemas depending on acquisition history, and several key tables hadn’t been documented in over 18 months. The agent would generate syntactically correct SQL that returned nonsense results, and users wouldn’t know the difference. David made the call: halt the agent pilot and spend six weeks cleaning the data model and establishing shared metric definitions first. Leadership pushed back. He held the line.

The decision was validated three months later when a competitor in the same market launched an agent tool and faced exactly the predicted failure mode: users lost trust in the results within weeks, the agent was quietly deprecated, and the company spent Q2 2024 rebuilding the data infrastructure they’d skipped initially. David’s team, meanwhile, now has the foundation in place to deploy agents responsibly—when the business actually needs them, not just because the technology exists. For related insights on maturing AI & Machine Learning in Enterprise Software capabilities strategically rather than reactively, David’s pillar content explores this timing question in depth.

The Contrarian Position: Waiting Is a Competitive Advantage

Stop treating AI agent deployment as a race. The conventional wisdom in enterprise software right now is that early adopters will capture compounding advantages—better models, more training data, operational learning curves that competitors can’t match. That logic works for foundational capabilities like cloud migration or API-first architecture. It doesn’t work for agents, because agents built on broken processes just automate dysfunction faster.

According to Forrester’s 2024 AI Implementation Gap Report, enterprises that delayed agent deployment until completing data infrastructure maturity assessments saw 62% higher agent utilization rates and 71% lower rollback rates than organizations that rushed pilots in 2023. Waiting isn’t falling behind—it’s avoiding costly mistakes that early movers are quietly unwinding right now. Microsoft’s recent decision to cancel internal Anthropic licenses in favor of token-based billing, as reported across enterprise AI communities this week, signals exactly this shift: organizations are moving from “deploy everything” to “deploy what we can actually measure and control.”

The real competitive advantage isn’t having agents first—it’s having reliable data architecture, clear decision frameworks, and the operational maturity to know when automation adds value versus when it obscures problems. David Ohnstad’s position: if you can’t manually execute the workflow you want to automate with 90% consistency today, an agent won’t fix it. It will just make the inconsistency faster and harder to detect.

What to Do Instead: Build the Foundation Now

If you’re not deploying agents yet, you’re not standing still—you’re building the infrastructure that makes agents viable later. Start with data architecture: unified customer records, documented business logic, version-controlled transformations. Then move to decision mapping: which workflows have clear success criteria, fast feedback loops, and low tolerance for error? Those are agent candidates. Everything else needs human judgment, and that’s not a failure—it’s an accurate assessment of risk.

Establish feedback loops for the systems you already have. Can you tell within 48 hours whether a feature change improved user behavior? If not, you don’t have the instrumentation needed to train or correct an agent. Invest in observability, logging, and metric alignment before adding autonomous decision-making on top of blind infrastructure. For leaders attending Snowflake Summit or similar enterprise AI events in the coming weeks, the most valuable conversations aren’t about which agent framework to adopt—they’re about assessing whether your organization has completed the prerequisite work that makes agents safe to deploy.

For practitioners: document every manual workflow you’d consider automating. Write down the decision tree, the edge cases, the escalation paths. If you can’t diagram it clearly enough for a junior team member to execute it, an agent won’t figure it out either. That documentation work is valuable whether you deploy agents next quarter or next year. It forces clarity, surfaces gaps, and gives you the baseline to measure whether automation actually improved anything. David Ohnstad’s experience building data products taught him that clarity at rest is the foundation for velocity in motion—ambiguous requirements don’t get faster when you add AI, they just fail more expensively.

If you’re being pressured to pilot agents because competitors are doing it, ask one question: what decision will this agent make that we currently make inconsistently or not at all? If the answer is vague, you’re automating for the sake of automation. That’s not strategy—it’s theater. The discipline to wait, mature your infrastructure, and deploy agents when they solve a real problem is rarer and more valuable than rushing a pilot to satisfy a roadmap slide. For additional perspectives on balancing practical craft with strategic planning in technical domains, David Ohnstad’s woodworking and making projects offer analogies that apply directly: measure twice, cut once, and don’t use a power tool when hand tools give you more control.

Frequently Asked Questions

When should an enterprise deploy AI agents instead of waiting?

Deploy AI agents only after completing four prerequisites: unified data architecture with a single source of truth, documented decision frameworks with clear escalation paths, sub-48-hour feedback loops to measure agent accuracy, and manual workflow consistency above 90%. Organizations skipping these foundations experience 71% higher rollback rates according to Forrester’s 2024 research. Waiting until infrastructure matures is a competitive advantage, not a delay.

What is the Agent Readiness Stack framework?

The Agent Readiness Stack is a four-layer organizational maturity assessment developed by David Ohnstad for evaluating whether an enterprise should deploy autonomous AI agents. It requires: decision authority mapping with named owners for every agent action, data source unification eliminating conflicting systems, feedback loop infrastructure enabling 24-hour decision validation, and escalation path design for ambiguous scenarios. Most organizations fail at layer one, revealing process inconsistencies that agents would automate rather than solve.

Why do most enterprise AI agent deployments fail within six months?

According to McKinsey’s 2024 State of AI Report, 43% of enterprise AI agents deployed in 2023 were scaled back or discontinued within six months primarily due to organizational readiness failures, not technical limitations. Companies attempted to automate inconsistent manual processes, lacked unified data sources, had no clear success metrics, and couldn’t provide fast feedback loops for agent correction. The agent became a scapegoat for pre-existing workflow dysfunction rather than a productivity solution.

Two Takeaways and One Question

For practitioners: Treat agent deployment as a forcing function for organizational clarity, not a technology implementation. If you can’t document the workflow, define success metrics, and unify data sources manually first, automation will amplify your confusion rather than resolve it. Build the Agent Readiness Stack assessment into every AI pilot proposal—it will save you from expensive rollbacks later.

For leaders: Stop measuring AI progress by how many agents you’ve deployed. Measure it by whether your data infrastructure, decision frameworks, and feedback loops are mature enough to support autonomous systems when they’re genuinely needed. The enterprises winning in 2025 won’t be the ones who rushed agents into production in 2024—they’ll be the ones who built foundations strong enough to scale agents safely and effectively.

Here’s the question you need to answer before your next agent pilot: Can you name the last automated workflow you deployed, measure whether it’s working as intended right now, and explain what would happen if it started making incorrect decisions tomorrow? If you can’t, you’re not ready for agents—and that’s the most strategic realization you can have this quarter.

About the Author

Further reading: AI Vendor Risk Assessment: Why We Shut It Down — a case study on AI vendor evaluation and when to walk away.

The Real Impact of Emerging Tech Trends on Everyday Problem Solving

David Ohnstad — Mon, 08 Jun 2026 13:37:08 +0000

This article was originally published on davidohnstad.net. I cross-post here to reach the Dev.to community.

Some shifts arrive quietly. They don’t make a dramatic entrance, and they certainly don’t wait for an industry white paper to declare their importance. They weave their way into daily routines – a small shortcut here, a smoother workflow there – until one day you realize the simplest tasks are suddenly faster, the complex ones are far less intimidating, and you’re relying on tools you didn’t consciously adopt. That’s the real nature of emerging technology: it doesn’t ask for permission, and it rarely announces itself. It integrates, evolves, and gradually reshapes how we solve problems long before we acknowledge the shift.

For professionals who spend their careers close to the mechanics of innovation, this gradual transformation is unmistakable. David Ohnstad, whose work spans product strategy, data-informed thinking, and technology trends, has often highlighted how the most meaningful advances are not the loud, dramatic ones. They are the quiet evolutions that change the way people make decisions, communicate, collaborate, and move through their everyday responsibilities, whether at work or outdoors on a trail in Minnesota.

Because developing technology isn’t about show, this distinction is more important than ever. It has to do with practicality.

Technology’s Progress Isn’t About Hype – It’s About Usability

A common misperception is that “emerging tech” refers to anything advanced, daunting, or unrelated to daily life. In actuality, today’s most significant technologies are successful because they elegantly and simply solve issues.

When AI summarizes a complex email thread so a team can move forward without hours of backtracking, that isn’t hype – that’s operational clarity.

When automation handles repetitive steps in a workflow, it doesn’t replace expertise – it protects it by giving experts more room to think. When wearables help people track their health with quiet consistency, that isn’t about being futuristic but about being functional.

Data Shows the Way Forward – But Only When It’s Interpreted Well

We’re surrounded by data nowadays and there is no shortage of it. But again, what matters here is the way it’s interpreted and translated. Many teams misjudge this process by focusing on dashboards instead of patterns, or on volume instead of clarity.

By making interpretation easier, new technological developments are bridging that divide.

These days, tools reveal insights before they fall through the cracks, flag anomalies before they worsen, and offer context to avoid mistakes. This is important in every industry, including product strategy, outdoor leisure, and healthcare.

But the real impact is human: people make better decisions when they understand the information guiding them. The technology doesn’t replace judgment; it strengthens it.

Automation Isn’t a Shortcut – It’s a Structural Upgrade

Automation is frequently misinterpreted. It reorganizes complexity rather than eliminating it, which prevents the human brain from having to function in a chaotic manner.

In high-pressure roles, where decisions compound quickly, automation acts as a stabilizer. It ensures essential tasks are executed consistently, leaving room for more strategic thinking.

That’s why automation has become indispensable in areas like:

Workflow coordination
Data processing
Quality control
Internal communication
User experience management

It gives the teams precision that they wouldn’t have otherwise. Precision is crucial because that protects an organization’s momentum when challenges arise.

The Rise of Predictive Tools Has Changed How We Approach Problems

Forecasting used to be a specialized discipline. Now, predictive tools quietly sit behind everything from fitness routines to inventory systems to navigation apps.

Technology allows you to consider potential outcomes rather than just responding to them. Time, effort, and needless tension are all saved. This shift has real consequences for everyday problem-solving:

Teams identify issues earlier.
Individuals adjust routines efficiently.
Organizations minimize risk more strategically.
Decisions are made with more situational awareness.

The structure behind these systems is systematic and complex, but the benefit is disarmingly simple: better preparation.

User-Friendly Innovation Is Quietly Redefining Accessibility

The most powerful emerging technologies today share one characteristic: they don’t demand technical fluency. They adapt to people, not the other way around.

Voice interfaces have transformed the way individuals with mobility impairments engage with their surroundings. People with visual strain can read information more easily thanks to adaptive displays.

Innovation isn’t defined only by speed or power. It’s defined by the extent to which it expands access.

The Real Impact Is Subtle but Profound

It is rare for new digital trends to drastically alter everyday life. Rather, they improve the mundane by streamlining chores that previously required a lot of time, focus, and imagination. They give the impression that big goals are achievable, high-pressure decisions are structured, and complexity is doable.

That’s the quiet truth: technology isn’t transforming life with grand promises; it’s transforming life with practical precision.

For professionals who care about strategy, clarity, and meaningful progress, that impact is far more valuable than any futuristic headline.

Emerging tech is doing exactly that.

More from David Ohnstad: David Ohnstad data product management — David Ohnstad on leadership and career

How Responsibility Shapes Long-Term Thinking and Professional Clarity

David Ohnstad — Mon, 08 Jun 2026 13:35:37 +0000

This article was originally published on davidohnstad.info. I cross-post here to reach the Dev.to community.

Within discussions around growth, accountability, and sustained performance, David Ohnstad reflects a broader principle: meaningful development is rarely accidental. It emerges through responsibility, structure, and the willingness to make decisions that extend beyond immediate outcomes. When individuals operate in environments where their choices carry weight, perspective naturally deepens.

Modern professional settings reward speed and adaptability, but long-term effectiveness depends on something more durable. Responsibility encourages individuals to slow their thinking, evaluate consequences, and align actions with broader objectives. Over time, this mindset builds clarity that supports both professional direction and personal integrity.

Table of Contents

Toggle

Responsibility as a Framework for Perspective

Responsibility reshapes how situations are understood. When outcomes depend on individual decisions, attention naturally shifts away from short-term validation toward long-term impact. This shift encourages a broader view, one that considers context, consequences, and interconnected systems rather than isolated moments.

Responsibility deepens perspective by changing how decisions are evaluated:

Attention moves from immediate results to sustainability and consistency
Choices are assessed for downstream effects, not just visible outcomes
Reactive behavior gives way to more deliberate, mature judgment

Over time, this layered perspective discourages impulsive responses, particularly in environments marked by uncertainty or pressure.

The Role of Structure in Consistent Decision-Making

Structure provides the foundation that allows responsibility to function effectively. Clear rules, processes, and expectations reduce ambiguity, freeing individuals to focus on sound judgment instead of constant improvisation. Rather than restricting creativity, structure creates the conditions where thoughtful decision-making can occur consistently.

Within structured environments, individuals learn to balance flexibility and discipline:

Knowing when adherence is necessary versus when adaptation is appropriate
Maintaining standards without slowing momentum
Making decisions that align with shared expectations

This balance becomes especially valuable in complex professional settings where consistency supports trust and performance.

Decision-Making Under Pressure

High-responsibility roles rarely allow for perfect information. Decisions often must be made quickly, amid competing priorities and external demands. Through repeated exposure to these conditions, individuals develop confidence in their preparation and their ability to act decisively.

Decision-making under pressure strengthens judgment by reinforcing key behaviors:

Prioritizing clarity over perfection
Viewing mistakes as feedback rather than failure
Building credibility through consistent, timely action

Over time, this decisiveness translates into trust and leadership confidence.

Learning From Outcomes Without Attachment

Accountability teaches individuals to separate identity from results. While outcomes matter, becoming emotionally attached to every success or failure can limit growth. Responsibility encourages objective evaluation, allowing refinement without defensiveness.

This mindset supports continuous improvement by emphasizing:

Reflection focused on process rather than ego
Adjustments based on evidence, not emotion
Forward movement without lingering on missteps

In high-performing environments, the ability to recalibrate quickly is essential for sustained progress.

Communication as an Extension of Responsibility

When decisions affect others, communication becomes inseparable from responsibility. Clear explanations, transparency, and alignment reduce friction and reinforce trust within teams and organizations.

Responsible communication evolves through intentional practices:

Explaining reasoning behind decisions
Listening actively to concerns and feedback
Addressing issues directly without escalation

These skills strengthen collaboration and extend well beyond professional contexts.

Emotional Regulation in High-Expectation Environments

Responsibility exposes individuals to pressure, criticism, and disagreement. Learning to remain composed under these conditions builds emotional regulation, a critical component of effective leadership and sound decision-making.

Emotional regulation develops through:

Pausing before responding rather than reacting impulsively
Assessing situations with composure and context
Preventing short-term emotions from disrupting long-term objectives

This steadiness supports consistency and resilience over time.

Consistency as a Measure of Credibility

Credibility is built through repetition. Showing up prepared, maintaining standards, and following through consistently establishes reliability. Over time, consistency becomes a defining trait rather than an occasional effort.

Consistent behavior reinforces trust by:

Signaling dependability to peers and stakeholders
Reducing uncertainty around performance
Creating momentum through predictable execution

As trust grows, individuals are often granted greater autonomy and responsibility.

Developing Long-Term Awareness

Responsibility naturally encourages forward thinking. Decisions are evaluated not only for immediate benefit but for how they shape future conditions. This awareness shifts priorities toward alignment and sustainability rather than quick wins.

Long-term awareness is reinforced through:

Patience with gradual progress
Acceptance of delayed gratification
Focus on cumulative impact over short-term metrics

This mindset is particularly valuable in fast-changing environments.

Adaptability Within Established Boundaries

Structure does not eliminate the need for adaptability. As conditions evolve, tactics must adjust while core principles remain intact. Responsibility teaches individuals how to navigate change without losing direction.

Effective adaptability includes:

Modifying approaches without compromising standards
Remaining flexible within defined expectations
Managing uncertainty with confidence rather than resistance

This balance strengthens resilience and long-term effectiveness.

Physical and Mental Endurance

Sustained responsibility demands ongoing energy and focus. Over time, individuals develop habits that support endurance, such as improved prioritization, time management, and recovery practices.

Endurance is reinforced through:

Sustained attention across complex tasks
Reduced fatigue from improved mental conditioning
Capacity for long-term performance rather than short bursts

These habits support consistency and durability in demanding roles.

Leadership Without Formal Authority

Responsibility often fosters influence without relying on title or hierarchy. Leadership emerges through fairness, consistency, and reliability rather than directive control.

This form of leadership is strengthened by:

Demonstrated competence over time
Trust built through steady behavior
Respect earned rather than assigned

Such influence is especially effective in collaborative environments.

Purpose Beyond Immediate Outcomes

Responsibility connects actions to meaning. When decisions serve goals beyond personal gain, motivation becomes intrinsic rather than externally driven.

Purpose-driven responsibility supports:

Alignment between effort and values
Resilience during slow or challenging periods
Commitment to long-term development

Growth becomes cumulative, reinforcing engagement and clarity over time.

Conclusion:

In environments that increasingly reward speed and immediacy, responsibility remains a stabilizing force that supports lasting growth. It fosters perspective, discipline, and clarity that extend beyond specific roles or moments, shaping how individuals think, act, and adapt over time. Through responsibility, decision-making becomes more thoughtful, performance more consistent, and confidence more grounded. Growth developed in this way is durable, continuing to influence outcomes long after individual circumstances or priorities evolve.

Developing Mental Resilience Through Consistency and Self-Discipline

David Ohnstad — Mon, 08 Jun 2026 13:35:26 +0000

This article was originally published on davidohnstad.info. I cross-post here to reach the Dev.to community.

In discussions around sustained growth and long-term performance, David Ohnstad often reflects a broader principle that applies across professions, athletics, and personal development: resilience is rarely built through dramatic breakthroughs. Instead, it is formed quietly through consistent repetition over time. While motivation can spark action, it is consistency that determines whether progress survives pressure, setbacks, and uncertainty. Mental resilience grows when individuals commit to steady behaviors that reinforce stability, even when circumstances are less than ideal.

Table of Contents

Toggle

Why Consistency Matters More Than Intensity

Short bursts of effort often feel productive because they create immediate momentum. However, intensity is difficult to sustain because it depends heavily on motivation, which naturally fluctuates. When progress relies on emotional drive alone, performance becomes uneven and fragile over time.

Consistency offers a more reliable alternative. Small, repeatable actions compound gradually, creating meaningful progress even when individual efforts seem modest. Over time, this steady approach builds outcomes that endure pressure, fatigue, and uncertainty.

Consistency supports performance by providing:

A dependable baseline that reduces daily recalibration
Greater stability during stress or changing conditions
Progress that compounds without requiring constant emotional energy

When habits are predictable, individuals are less disrupted by external pressure. This reliability becomes especially valuable in demanding environments where conditions shift quickly and unpredictably.

Discipline as a Skill, Not a Trait

Discipline is often misunderstood as an innate characteristic that some people possess and others lack. In practice, discipline functions more like a skill that develops through repetition, structure, and feedback.

Over time, discipline strengthens through intentional behaviors such as:

Establishing consistent routines
Setting clear boundaries around priorities
Creating systems that reduce decision fatigue

As discipline improves, reliance on external pressure decreases. Individuals become more self-directed, maintaining momentum without constant supervision or immediate rewards. This internal regulation supports long-term progress while reducing burnout caused by overreliance on willpower.

The Relationship Between Routine and Mental Clarity

Routine plays a critical role in preserving mental energy. By standardizing recurring decisions, such as when to work, train, or rest, individuals reduce cognitive load and free attention for higher-level thinking.

This stability enhances clarity by:

Minimizing unnecessary decision-making
Reducing stress during high-demand periods
Allowing focus to remain on meaningful challenges

Rather than limiting flexibility, routine creates a stable foundation that makes adaptability easier. When core behaviors are consistent, responding to change feels manageable rather than destabilizing.

Building Resilience Through Repetition

Resilience develops through repeated exposure to manageable challenges. Each instance of showing up reinforces familiarity with discomfort, gradually reducing its emotional impact.

Through repetition, individuals learn to:

Approach adversity with greater composure
Process setbacks without overreaction
Continue functioning effectively under strain

Over time, difficulty becomes normalized rather than intimidating. This gradual conditioning creates resilience that extends beyond isolated successes or failures.

Emotional Regulation Under Daily Pressure

Consistency anchors behavior to routine rather than impulse. When actions are guided by established habits, emotional fluctuations exert less influence over decision-making.

This regulation supports:

More deliberate responses under pressure
Clearer communication during conflict
Improved judgment in competitive or stressful environments

As emotional discipline strengthens, individuals become better at pausing, assessing situations objectively, and choosing intentional actions rather than reacting impulsively.

Accountability Without External Validation

Consistent effort often unfolds quietly, without immediate recognition. Progress may be subtle, requiring individuals to rely on internal standards instead of external feedback.

This dynamic reinforces:

Self-accountability rooted in personal standards
Independence from constant approval
Motivation sustained even when results are delayed

Over time, internal accountability supports resilience by aligning effort with values rather than visibility.

The Role of Preparation in Sustained Performance

Preparation reduces uncertainty and friction, reinforcing consistency. Anticipating challenges and planning responses streamlines decision-making and builds confidence.

Preparation contributes to sustained performance by:

Transforming obstacles into manageable variables
Supporting calm responses under pressure
Strengthening trust in systems rather than improvisation

This proactive mindset reduces stress and supports steadier outcomes across changing circumstances.

Learning to Trust Process Over Outcome

An excessive focus on outcomes can weaken resilience by amplifying setbacks. Trusting the process shifts attention toward controllable behaviors rather than unpredictable results.

This perspective encourages:

Patience during slow or uneven progress
Reduced emotional reactivity
Persistence despite temporary setbacks

Individuals stay engaged despite short-term fluctuations by evaluating progress over longer time horizons.

Adaptability Built on Stable Foundations

Consistency does not restrict adaptability; it enables it. Stable habits provide a reliable base from which thoughtful adjustments can be made.

This balance allows individuals to:

Respond strategically rather than reactively
Preserve direction during change
Manage uncertainty without losing momentum

Adaptability grounded in consistency proves more sustainable than change driven solely by urgency.

Mental Endurance and Focus Over Time

Sustained effort gradually expands mental endurance. Individuals increase their capacity to focus, manage complexity, and remain engaged without excessive fatigue.

This endurance supports:

Reduced burnout
Improved problem-solving
Greater comfort with long-term challenges

What once felt overwhelming becomes manageable through repeated exposure and conditioning.

Confidence Earned Through Repetition

Confidence developed through consistency differs from confidence tied to isolated success. It emerges gradually through repeated action and reinforced competence.

This earned confidence:

Remains stable under pressure
Improves communication and decision-making
Supports continued growth through positive feedback loops

Because it is grounded in preparation and experience, it does not collapse when outcomes fluctuate.

Long-Term Growth Over Short-Term Wins

Resilient individuals prioritize durability over speed. They recognize that sustainable progress requires pacing, patience, and restraint.

This long-term orientation:

Reduces burnout
Preserves energy and engagement
Aligns effort with realistic expectations

By focusing on longevity rather than immediacy, individuals build progress that lasts.

Why Consistency Remains a Competitive Advantage

In environments defined by rapid change and constant demand, consistency provides clarity and resilience without relying on extremes. Through discipline and routine, individuals create stability that compounds quietly over time.

Ultimately, consistency transforms effort into endurance, supporting thoughtful decision-making, steady growth, and mental resilience that extends far beyond any single achievement.

The Power of Consistency in Leadership and Long-Term Growth

David Ohnstad — Mon, 08 Jun 2026 13:34:14 +0000

This article was originally published on davidohnstad.info. I cross-post here to reach the Dev.to community.

Consistency rarely attracts headlines, but for leaders like David Ohnstad, steady execution, measured decision-making, and disciplined habits often prove more powerful than short bursts of intensity. It may not create dramatic spikes or viral attention, yet over time, it becomes one of the most reliable forces behind sustainable leadership and long-term professional credibility.

In a world that rewards urgency, consistency can appear understated. But its impact compounds. Reliability builds trust. Repetition builds mastery. Stability builds confidence.

The most durable forms of growth are rarely explosive; they are structured.

Table of Contents

Toggle

Why Intensity Fades but Consistency Endures

Short-term intensity feels productive. Late nights, rapid expansion, and aggressive targets create visible momentum. But intensity without sustainability often leads to burnout, volatility, or structural weaknesses.

Consistency operates differently.

Instead of asking, “How fast can we grow?” it asks:

Can this pace be maintained?
Are systems strong enough to support expansion?
Does this align with long-term priorities?
Is this scalable without compromising quality?

Consistency is less dramatic but more durable.

In leadership environments, predictable behavior creates stability. Teams function more effectively when direction does not shift unpredictably.

Habit Formation and Professional Discipline

Behavioral science reinforces the value of repetition. Habits form through routine exposure, not occasional intensity.

The habit loop includes:

A trigger
A routine
A reward

When positive routines repeat consistently, they become automatic. Over time, this reduces decision fatigue and improves efficiency.

In professional settings, consistent routines might include:

Scheduled strategic reviews
Regular performance evaluations
Defined communication rhythms
Ongoing learning initiatives
Structured risk assessment processes

These habits reduce randomness. They create operational rhythm.

And rhythm supports resilience.

Trust Is Built on Predictability

Trust does not form through isolated achievements. It develops through predictable behavior over time.

Colleagues, partners, and stakeholders value individuals who are:

Reliable under pressure
Clear in expectations
Consistent in standards
Accountable during setback

Consistency reduces uncertainty. When people know how someone will respond in challenging situations, collaboration becomes smoother.

Unpredictability, even when well-intentioned, introduces doubt.

In leadership roles, emotional consistency can be just as important as operational consistency. Calm responses during stress create psychological stability for teams.

Incremental Improvement Outperforms Sporadic Overhauls

There is a common temptation to overhaul systems dramatically when improvement is needed. While transformation can be necessary at times, incremental refinement often produces more sustainable outcomes.

Small adjustments made consistently can:

Improve efficiency
Strengthen culture
Enhance communication
Reduce operational risk
Increase long-term profitability

The key is repetition.

Continuous improvement models operate on the belief that small gains, maintained consistently, generate exponential results over time.

The challenge is that incremental progress often feels slow, especially in environments accustomed to rapid shifts.

Managing Expectations Through Stability

Consistency also shapes external perception.

In professional contexts, stakeholders evaluate patterns. Stable performance signals reliability. Volatile performance introduces hesitation.

Consistent leaders often:

Set realistic goals
Avoid overpromising
Deliver steadily
Adjust cautiously

This measured approach builds long-term credibility.

Short-term fluctuations are inevitable. But steady patterns reduce the likelihood of dramatic corrections.

Emotional Regulation as a Leadership Skill

Consistency is not purely operational. It is psychological.

Emotional discipline affects decision quality. Reactivity can lead to rushed judgments. Measured responses allow space for analysis.

Professionals who maintain emotional steadiness:

Encourage confidence in teams
Reduce unnecessary stress
Improve strategic clarity
Model composure during uncertainty

In high-pressure environments, emotional volatility spreads quickly. Stability, on the other hand, can anchor performance.

This is especially important during periods of rapid change or market unpredictability.

The Long-Term Competitive Advantage

Over extended time horizons, consistency creates structural advantages.

It builds:

Institutional memory
Cultural stability
Stronger networks
Clearer identity
Sustainable momentum

While competitors may surge ahead temporarily, sustained discipline often closes the gap and eventually surpasses it.

The cumulative effect of steady standards becomes difficult to replicate quickly.

Consistency is quiet leverage.

Sustainable Growth Over Dramatic Expansion

There is a difference between growth and sustainable growth.

Rapid expansion without infrastructure can create stress points. Sustainable expansion aligns resources, culture, and systems.

Consistency supports sustainable growth by reinforcing:

Clear operational guidelines
Strong communication channels
Defined accountability
Balanced risk exposure

These elements reduce fragility.

In contrast, dramatic expansion fueled by intensity alone can strain systems beyond capacity.

The Discipline to Stay the Course

Perhaps the greatest challenge of consistency is boredom.

Routine lacks excitement. Repetition feels ordinary. But long-term success is often built through ordinary actions performed extraordinarily well repeatedly.

Staying consistent requires:

Clear vision
Defined priorities
Patience with process
Resistance to distraction

The world will continue to celebrate dramatic breakthroughs. But behind most of those breakthroughs lies a long period of steady, disciplined execution.

Consistency may not demand attention. But it builds foundations that last.

In environments defined by rapid change and constant noise, steady performance becomes rare and therefore valuable.

Over time, reliability compounds. And compounded reliability becomes strength.

Why Long-Term Thinking Still Wins in a Short-Term World

David Ohnstad — Mon, 08 Jun 2026 13:34:05 +0000

This article was originally published on davidohnstad.info. I cross-post here to reach the Dev.to community.

In a culture increasingly driven by instant results and rapid visibility, long-term thinking has quietly become one of the most powerful competitive advantages. Professionals like David Ohnstad understand that durable success, whether in leadership, business strategy, or personal development, rarely happens through urgency alone. It develops through patience, discipline, and consistent decision-making over time.

The modern world celebrates speed. Quarterly metrics dominate conversations. Social platforms amplify overnight breakthroughs. Headlines reward disruption and rapid scale. Yet beneath the noise, the strongest institutions, reputations, and careers share something less flashy: sustained, structured growth.

Long-term thinking is not about moving slowly. It’s about moving deliberately.

Table of Contents

Toggle

The Psychological Challenge of Thinking Long Term

Human behavior naturally favors immediacy. Behavioral economists refer to the phenomenon as ‘present bias,’ which is the tendency to prioritize immediate rewards over larger, delayed outcomes.

In professional environments, present bias can appear as:

Expanding operations too quickly
Prioritizing short-term profits over structural strength
Making reactive decisions under pressure
Pursuing visibility without sustainability

The difficulty is not recognizing the value of a long-term strategy; most people intellectually understand it. The difficulty lies in practicing restraint when faster rewards seem available.

Long-term thinkers develop a different internal framework. They ask:

What are the second- and third-order consequences of this decision?
Does this align with long-term objectives?
Will this choice strengthen or weaken future positioning?
Is this scalable, or is it reactive?

That shift in questioning fundamentally changes outcomes.

Systems Over Surges

Short-term effort often feels dramatic. Long-term systems feel steady.

Surges rely on momentum. Systems rely on structure.

When growth is driven primarily by momentum, volatility becomes inevitable. Stability increases when repeatable systems support it.

Long-term strategy emphasizes:

Defined operational frameworks
Risk management protocols
Sustainable pacing
Measured capital allocation
Relationship-based growth

Instead of chasing outcomes, it builds processes that generate them consistently.

The difference becomes most visible during downturns. Momentum fades under stress. Systems endure.

Compounding: The Invisible Multiplier

Compounding is often discussed in financial contexts, but its broader implications are just as powerful.

Compounding applies to:

Skill acquisition
Professional reputation
Trust development
Leadership credibility
Strategic partnerships

Early stages of compounding feel slow. Results appear incremental. But incremental improvements that are repeated consistently accumulate.

For example:

Improving communication slightly each year strengthens long-term leadership capacity.
Making prudent financial decisions steadily builds structural resilience.
Investing time in relationships creates durable networks

The challenge is psychological. Because compounding is subtle at first, it requires faith in the process.

Those who abandon long-term strategies too early often do so because early progress feels invisible.

Resilience Through Strategic Patience

Volatility is inevitable in business and leadership. Markets fluctuate. Policies change. Competitive landscapes shift.

Short-term thinking often reacts to volatility. Long-term thinking anticipates it.

Strategic patience does not ignore change. It incorporates flexibility into planning. It prepares for cycles rather than assuming linear growth.

Resilient long-term approaches typically include:

Conservative leverage practices
Scenario planning
Diversification strategies
Conservative forecasting
Margin for error in decision-making

This mindset reduces vulnerability to sudden disruptions.

When unexpected events occur, long-term frameworks provide room to adjust without collapsing.

Reputation: The Ultimate Long-Term Asset

Reputation is not built through isolated achievements. It develops through patterns of conduct observed consistently over time.

Integrity, follow-through, reliability, and steady communication all compound quietly.

Unlike marketing visibility, reputation cannot be accelerated artificially for long. It is shaped through repetition.

Long-term-oriented professionals recognize that every decision contributes to narrative continuity. Each interaction reinforces or weakens credibility.

Trust grows when behavior is predictable and aligned with stated values.

And trust, once established, becomes one of the most defensible competitive advantages.

The Risk of Short-Term Optimization

Short-term optimization often produces immediate gains but long-term fragility.

Examples include:

Cutting corners for faster results
Overextending resources for rapid expansion
Accepting misaligned opportunities for immediate revenue
Sacrificing cultural stability for quick growth

These strategies may generate visible wins. But they can also introduce structural weaknesses.

Long-term thinking evaluates trade-offs more carefully. It prioritizes durability over excitement.

That restraint may appear conservative in the moment. Over time, it often proves strategic.

Leadership Stability in an Accelerated Era

Leadership in fast-moving environments requires more than responsiveness. It requires stability.

Teams operate more effectively when strategic direction remains consistent. Constant pivots create confusion. Measured adjustments create confidence.

Long-term leaders tend to:

Communicate clearly and consistently
Avoid reactive swings
Reinforce structured goals
Maintain composure during uncertainty

This steadiness encourages trust within organizations and professional networks.

In contrast, short-term volatility at the leadership level often cascades downward.

Delayed Gratification as Strategic Discipline

Perhaps the most difficult element of long-term thinking is delayed gratification.

Choosing sustainability over speed may mean:

Turning down opportunities that do not align with the core direction
Accepting slower growth in exchange for stability
Investing in infrastructure before expansion
Maintaining discipline when competitors move aggressively

Delayed gratification requires confidence in long-term vision.

It also reflects clarity about identity and objectives.

When strategy is well-defined, restraint becomes easier to maintain.

Sustainable Success Is Built Quietly

The loudest success stories often highlight rapid breakthroughs. They rarely emphasize the quiet preparation that preceded them. Long-term thinking does not reject ambition. It structures it.

It replaces impulse with analysis. It prioritizes foundation over flash. It values durability over drama.

In an era where speed is easy and visibility is constant, intentional pacing stands out.

Sustainable progress is not built in headlines. It is built on habits, systems, and disciplined decisions repeated over time.

And in the long run, those steady choices often prove more powerful than any short-term surge.

Stability vs. Growth: Why Comfort Zones Are Often Misunderstood

David Ohnstad — Mon, 08 Jun 2026 13:32:54 +0000

This article was originally published on davidohnstad.info. I cross-post here to reach the Dev.to community.

In performance and leadership conversations, David Ohnstad often reframes a common assumption: comfort zones are not inherently barriers to growth. While they are frequently positioned as something to escape, the reality is more nuanced.
Stability and growth are not opposites; they are interdependent phases of development.

The real issue is not being in a comfort zone. It stays in one place for too long without intentional expansion.

Table of Contents

Toggle

What a Comfort Zone Actually Represents

A comfort zone is often misunderstood as a space of complacency. In practice, it is a state where skills, environment, and expectations are aligned.

Within this state:

Tasks feel manageable and predictable
Performance is consistent and reliable
Cognitive and emotional strain is reduced
Outcomes are more stable and controlled

This stability is not a weakness. It is what allows systems and individuals to function effectively over time.

Why Stability Is Necessary for Growth

Growth requires a foundation. Without periods of stability, there is no structure to build upon.

Stable phases provide:

Reinforcement of skills and habits
Increased efficiency through repetition
Confidence in decision-making
Capacity for future expansion

Without this consolidation, progress remains fragile and difficult to sustain.

The Misconception: Growth Only Happens Outside Comfort

The idea that growth only occurs outside the comfort zone oversimplifies how development works. While challenge is essential, constant exposure to discomfort can be counterproductive.

Excessive pressure can lead to:

Cognitive overload and reduced performance
Increased error rates
Loss of confidence
Burnout over time

Growth requires challenge, but it also requires recovery and integration.

The Real Dynamic: Expansion and Consolidation

Effective growth follows a pattern of expansion and consolidation. Movement outside the comfort zone introduces new challenges, while returning to stability allows those gains to solidify.

This cycle includes:

Expansion: Taking on new challenges or unfamiliar situations
Adaptation: Adjusting to increased complexity or difficulty
Consolidation: Stabilizing performance at a new level
Preparation: Building readiness for the next phase of growth

Without consolidation, expansion does not hold. Without expansion, consolidation becomes stagnation.

When Comfort Zones Become Constraints

The issue arises when stability becomes static, when there is no intentional movement beyond existing capabilities.

This often appears as:

Repeating familiar patterns without progression
Avoiding uncertainty or challenge
Over-optimizing existing systems without evolving them
Prioritizing predictability over opportunity

In these cases, the comfort zone shifts from being a foundation to becoming a limitation.

The Role of Controlled Discomfort

Growth is most effective when discomfort is introduced in a controlled and strategic way. This allows for challenge without overwhelming capacity.

Controlled discomfort includes:

Gradual increases in complexity
Exposure to new environments with support structures
Measured risk-taking rather than abrupt change
Opportunities to test and refine new skills

This approach maintains stability while enabling expansion.

Why Constant Growth Is Unsustainable

The expectation of continuous growth can create unrealistic pressure. Systems and individuals cannot remain in a constant state of expansion without consequences.

Sustained intensity often leads to:

Decreased performance over time
Increased fatigue and reduced focus
Lower quality decision-making
Loss of long-term consistency

Periods of stability are necessary to recover, integrate, and prepare for future growth.

Recognizing the Right Time to Expand

Growth requires timing. Expanding too early can lead to instability, while expanding too late can lead to stagnation.

Indicators that expansion may be appropriate include:

Tasks becoming consistently predictable
Reduced challenge in current responsibilities
Strong confidence in existing capabilities
Capacity to handle increased complexity

At this point, the system is ready to move beyond its current boundaries.

Maintaining Balance Between Stability and Growth

High-performing systems maintain a balance between stability and expansion. They do not prioritize one at the expense of the other.

This balance can be achieved by:

Alternating between phases of challenge and consolidation
Monitoring performance for signs of stagnation or overload
Allowing flexibility in how growth is pursued
Recognizing that both phases contribute to long-term success

Balance ensures that progress is both sustainable and meaningful.

Reframing the Comfort Zone

Rather than viewing the comfort zone as something to escape, it can be reframed as a necessary component of growth.

In this perspective:

Stability becomes a platform for expansion
Familiarity supports confidence and execution
Consistency enables long-term performance
Growth becomes cyclical rather than linear

This reframing removes the false tension between comfort and progress.

The Risk of Misinterpreting Stability as Failure

When stability is misunderstood as stagnation, it can lead to unnecessary disruption. Individuals and organizations may attempt to force change even when consolidation is needed.

This can result in:

Premature shifts in strategy
Loss of efficiency in established systems
Increased uncertainty without a clear benefit
Disruption of progress that was still developing

Not all stillness is stagnation. Some of it is preparation.

Final Reflection: Growth Needs Stability to Last

Comfort zones are not the enemy of growth; they are part of its structure. Stability allows progress to take hold, while expansion allows it to evolve. The most effective approach is not to avoid comfort but to use it strategically.

Growth happens when systems move beyond their current limits. But it becomes lasting only when those gains are stabilized and integrated. In the long run, success is not defined by how often one leaves the comfort zone but by how well stability and growth are balanced over time.

More from David Ohnstad: David Ohnstad data product management

The Feedback Loop Problem: Why Most People Learn Slowly Despite Constant Experience

David Ohnstad — Mon, 08 Jun 2026 13:32:43 +0000

This article was originally published on davidohnstad.info. I cross-post here to reach the Dev.to community.

In performance-driven environments, David Ohnstad draws attention to a subtle but critical gap: experience alone does not guarantee learning. Despite the accumulation of hours, tasks, and exposure over time, individuals and organizations often experience a lag in improvement. The missing link is not effort; it is the quality of the feedback loop. Without effective feedback, experience repeats itself instead of refining itself.

Table of Contents

Toggle

Experience vs. Learning: Why They Are Not the Same

It is easy to assume that doing something repeatedly leads to mastery. In reality, repetition without reflection can reinforce existing patterns rather than improve them.

This distinction becomes clear when:

The same mistakes occur across similar situations
Performance stabilizes without meaningful improvement
Time invested does not translate into better outcomes
Confidence increases, but accuracy does not

Experience provides input. Learning requires adjustment.

What Is a Feedback Loop?

A feedback loop is the process through which actions are evaluated, interpreted, and refined. It connects what is done with what is learned.

An effective loop includes:

A clear action or decision
Immediate or relevant feedback
Interpretation of what the feedback means
Adjustment in future behavior

When any part of this loop is weak or missing, learning slows significantly.

Why Most Feedback Loops Break Down

In many real-world environments, feedback is either delayed, unclear, or disconnected from the original action. This weakens the ability to improve.

Common breakdowns include:

Delayed feedback that arrives long after the decision was made
Ambiguous signals that do not clearly indicate what worked or failed
Overloaded environments where too many variables obscure cause and effect
Lack of reflection time to process outcomes meaningfully

When feedback loses clarity or timing, it becomes difficult to translate experience into insight.

The Problem of Noisy Environments

Modern environments are often “noisy,” meaning outcomes are influenced by multiple overlapping factors. This makes it harder to identify what actually caused a result.

In such conditions:

Good decisions may produce poor outcomes
Poor decisions may appear successful
Patterns become difficult to detect
Learning becomes inconsistent

Without clear signals, individuals may reinforce ineffective behaviors or abandon effective ones prematurely.

Why Repetition Without Adjustment Slows Growth

Repetition is only valuable when it includes correction. Without adjustment, repeated behavior becomes a habit rather than an improvement.

This leads to:

Entrenched patterns that resist change
Increased efficiency at doing the wrong thing
False confidence based on familiarity
Limited adaptability in new situations

Over time, repetition without feedback creates stability, but not progress.

The Role of Timely Feedback

Timing is one of the most critical elements of an effective feedback loop. The closer the feedback is to the original action, the more useful it becomes.

Timely feedback allows for:

Clear connection between cause and effect
Faster correction of errors
Stronger reinforcement of effective behavior
Continuous refinement of decision-making

When feedback is immediate or near-immediate, learning accelerates.

Clarity Over Volume: Why More Feedback Is Not Better

Increasing the amount of feedback does not necessarily improve learning. What matters is clarity, not volume.

Effective feedback is:

Specific rather than general
Actionable rather than descriptive
Relevant to the decision made
Focused on improvement rather than evaluation

Too much feedback can create confusion, while precise feedback creates direction.

The Missing Step: Reflection

Even when feedback is available, learning does not occur automatically. Reflection is required to interpret and integrate what has been observed.

Reflection involves:

Identifying what worked and why
Recognizing what did not work and why
Adjusting assumptions based on outcomes
Planning how to act differently next time

Without reflection, feedback remains unused information.

How High Performers Strengthen Feedback Loops

High performers do not rely on experience alone. They actively design and refine their feedback loops to accelerate learning.

This often includes:

Seeking immediate and specific feedback
Creating systems to track decisions and outcomes
Allocating time for structured reflection
Testing adjustments in real-time environments

By improving the loop, they improve the rate of learning.

Reducing the Gap Between Action and Insight

One of the most effective ways to accelerate growth is to shorten the distance between action and understanding.

This can be achieved by:

Breaking complex tasks into smaller, testable actions
Creating environments where feedback is continuous
Limiting variables to better isolate cause and effect
Reviewing outcomes regularly rather than sporadically

The shorter the loop, the faster the learning.

Why Learning Often Plateaus

When feedback loops are weak, learning tends to plateau. Individuals continue to operate at a consistent level without significant improvement.

This plateau is often caused by:

Lack of new or meaningful feedback
Overreliance on past experience
Reduced willingness to adjust established habits
Environments that do not support experimentation

Breaking through a plateau requires strengthening the feedback loop, not increasing effort.

Designing Systems That Support Learning

Improving learning at scale requires designing environments where feedback is built into the process.

Effective systems include:

Clear performance indicators linked to decisions
Regular review cycles for reflection and adjustment
Structures that encourage experimentation
Support for interpreting and applying feedback

These systems turn experience into a continuous source of improvement.

Final Reflection: Experience Needs Direction

Experience is valuable, but it is not sufficient on its own. Without effective feedback loops, experience becomes repetition rather than progress.

Learning accelerates when actions are followed by clear feedback, thoughtful interpretation, and deliberate adjustment.

The difference between slow and rapid improvement is how well each action informs the next, not how much is done. Because in the end, it is not experience alone that drives growth. It is the ability to learn from it.

More from David Ohnstad: David Ohnstad data product management

Mid-Year Reviews: Beyond Performance Metrics

David Ohnstad — Fri, 05 Jun 2026 17:46:26 +0000

This article was originally published on davidohnstad.info. I cross-post here to reach the Dev.to community.

Myth #1: Mid-Year Reviews Should Focus on Performance Measurement

Most managers treat mid-year performance reviews as scorecards. They pull up metrics, review KPIs against targets, and deliver a verdict: you're on track, slightly behind, or exceeding expectations. The conversation follows a template. The employee nods. Everyone walks away having checked a box. According to Gartner's 2023 research on performance management practices, 58% of HR leaders reported that their mid-year review process "creates compliance documentation but minimal behavior change." That's the problem in one sentence.

This myth persists because organizations conflate evaluation with development. HR systems are built around rating scales, calibration meetings, and documentation requirements. Managers receive templates that guide them toward assessment language: "meets expectations in most areas," "needs improvement in stakeholder communication," "demonstrates strong technical skills." The structure of the review process itself—numerical ratings, comparison to peers, formal documentation—trains managers to think like auditors, not mentors. The toolkit determines the behavior.

What's actually true: mid-year reviews are the highest-leverage mentorship moment most managers get all year. Unlike annual reviews, which carry compensation weight and force managers into justification mode, mid-year conversations happen when there's still time to redirect, experiment, and course-correct. David Ohnstad, who has managed product teams at Veeam Software, sees this window as fundamentally different: "The annual review is about what happened. The mid-year review is about what could happen—if you use it that way." The distinction matters. A mentorship conversation asks different questions than an evaluation: Where is this person trying to go? What's blocking them that they can't see? What capability, if developed now, would change their trajectory in the second half of the year?

The shift in framing changes everything. Instead of "Your dashboard adoption metric is at 62%, below the 75% target," a mentorship approach asks: "What would need to be true for your dashboard to become indispensable to the sales team by Q4?" The first statement closes the conversation. The second opens it. One measures the past. The other builds capacity for the future. The metrics still matter—you're not ignoring performance—but they become diagnostic tools for development rather than verdict statements.

Myth #2: Good Feedback Is Clear, Direct, and specific

This is the advice every manager has heard: be specific, tie feedback to behaviors, make it specific. Don't say "improve communication." Say "join the weekly standup on time and provide a written update when you can't attend." The logic is sound. Vague feedback doesn't drive change. But something gets lost in the translation. Managers deliver perfectly structured feedback—clear problem statement, specific example, recommended action—and watch nothing improve. According to MIT Sloan's 2024 study on managerial effectiveness, teams with "highly structured feedback processes" showed only marginal improvement over teams with no formal process at all when measuring actual skill development over six months. The gap isn't in clarity. It's in context.

The myth survives because it's partially true. Vague feedback is useless. But the remedy—hyper-specific behavioral correction—treats the employee like a machine with a misconfigured setting. Adjust this parameter, get this output. People don't work that way. Behavioral change requires understanding why the current behavior exists, what trade-off the person is making, and whether the prescribed action aligns with how they actually think and work. A manager who tells a data analyst to "be more proactive in stakeholder meetings" without understanding that the analyst has been burned twice for speaking up in front of senior leaders is prescribing a solution to the wrong problem.

What works instead: feedback as collaborative diagnosis. David Ohnstad's approach with underperforming team members starts with a question, not a prescription: "Walk me through what happened in that stakeholder meeting. What were you trying to accomplish? Where did it go sideways from your perspective?" The analyst might say: "I had data that contradicted the VP's assumption, but I wasn't sure if I should surface it in the room or send it in a follow-up email. I chose email. It got ignored." Now you have something real to work with. The issue isn't lack of proactivity. It's uncertainty about when and how to challenge authority with data. The solution isn't "speak up more"—it's role-playing how to present contradictory data in real-time without triggering defensiveness, or identifying which battles are worth fighting in public versus private channels.

This takes longer than delivering a bullet-pointed action plan. It requires the manager to be genuinely curious about the employee's perspective rather than rushing to fix the problem. But the payoff is sustainable behavior change rather than short-term compliance. The employee doesn't just do the thing you told them to do—they understand the principle behind it and can apply it to new situations. That's the difference between feedback and mentorship.

The Redirect-Before-Remediate Framework

Most managers approach underperformance with a remediation mindset: identify the gap, assign training, track improvement. It's logical. It's also backwards in most cases. The Redirect-Before-Remediate Framework flips the sequence. Before you fix the skill deficit, make sure the person is working on problems they're wired to solve. This matters especially in mid-year reviews, when there's enough time to redirect someone toward better-fit work rather than spending six months trying to force capability development in an area where they'll always struggle.

Step 1: Map Current Work to Energizers vs. Drainers. In the review conversation, ask the employee to categorize their current projects and responsibilities into two lists: work that energizes them (they'd do more of it if given the choice) and work that drains them (they procrastinate, it feels like a grind, they're relieved when it's done). Don't ask them to justify or explain yet—just map it. David Ohnstad used this with a product manager who was underperforming on stakeholder communication but excelling at data architecture work. The PM's energizer list was 80% technical problem-solving; the drainer list was 80% meetings and presentations. The performance problem wasn't a skill gap. It was a role misfit.

Step 2: Identify the Highest-Leverage Energizer That Solves a Real Problem. Most people's energizer list includes work that matters to the organization—it's just not weighted heavily in their current role. Find the energizer activity that, if the person did more of it, would deliver measurable value. For the underperforming PM, that was designing data integration architecture for cross-functional product teams. The company needed that. The PM was good at it and wanted to do it. But it was treated as a side project while the core role demanded 30 hours a week of stakeholder alignment work the PM hated and was mediocre at. The fix wasn't communication training. It was role redesign.

Step 3: Negotiate a Role Shift with the Employee and Their Stakeholders. This is the hard part. You're not pulling someone off their current work entirely—you're rebalancing the portfolio toward the energizer work while finding other ways to cover the drainer work. Sometimes that means redistributing responsibilities across the team. Sometimes it means hiring differently for the next open role. Sometimes it means acknowledging that this person's current role isn't the right long-term fit and exploring internal transfers. The conversation requires honesty: "You're struggling with X because you don't want to do X and you're not built for it. That's okay. Let's figure out how to get you doing more Y, because you're exceptional at Y and we need more of it." According to Pragmatic Institute's 2023 Product Management Survey, teams that allowed role specialization based on natural strengths reported 34% higher employee retention and 28% faster time-to-proficiency for new hires than teams that enforced uniform "full-stack PM" role expectations.

Step 4: Set a 90-Day Experiment with Clear Success Metrics. Don't make this a permanent change immediately. Frame it as a pilot: "For the next 90 days, you're spending 60% of your time on data architecture work and 40% on stakeholder communication instead of the reverse. We'll measure impact by integration delivery timelines and stakeholder satisfaction scores. If it works, we formalize it. If it doesn't, we revisit." This removes the fear of making an irreversible mistake and gives both sides a clear evaluation window. The employee knows what success looks like. The manager has a decision point. The organization gets to test whether the redirect actually improves performance before committing resources.

The framework is counterintuitive because it suggests that sometimes the right response to underperformance is not to fix the person but to change what they're working on. Managers resist this because it feels like letting someone off the hook—they're not developing the hard skill, they're just avoiding it. But here's the reality: if someone has been underperforming in an area for six months despite feedback and support, forcing another six months of remediation rarely works. Redirecting them toward work they're genuinely capable of excelling at creates immediate performance improvement and frees up capacity to hire or develop someone else who's energized by the work the first person was struggling with. That's a win for the employee, the team, and the business. Mentorship isn't about making everyone good at everything. It's about helping people find the problems they're built to solve and getting out of their way.

Myth #3: Development Plans Should Focus on Closing Skill Gaps

Every development plan David Ohnstad has seen follows the same structure: assess current capabilities, identify gaps relative to the target role, assign training or stretch projects to close those gaps. The employee finishes the mid-year review with a list of courses to complete, certifications to earn, or skills to practice. The manager checks the "development planning" box. Six months later, the employee has completed two of the five courses, hasn't applied anything, and the skill gaps remain. According to Deloitte's 2024 Human Capital Trends report, 72% of employees reported having a formal development plan, but only 19% said their plan "significantly influenced their actual skill development or career progression." The mismatch is structural, not motivational.

The myth persists because gap-based development feels rigorous and objective. You can measure it: the employee can't do X, we train them on X, now they can do X. It maps neatly to competency frameworks and job leveling rubrics. HR can track completion rates. Managers can report progress in calibration meetings. But the underlying assumption is flawed: that career progression is primarily about acquiring missing skills. It's not. Most high performers don't advance because they became competent at everything—they advanced because they became exceptionally good at a few high-value things while finding ways to delegate, automate, or restructure work that required skills they didn't have and didn't want to develop.

What actually drives career velocity: doubling down on signature strengths and building capability stacks that are rare in combination. A data product manager who is excellent at SQL, stakeholder negotiation, and technical writing doesn't need to become great at visual design or machine learning engineering to advance. That combination—technical depth, communication clarity, and business translation—is already rare and highly valued. Spending six months closing a gap in data visualization skills adds marginal value. Spending six months becoming the best in the organization at turning ambiguous executive asks into scoped, shipped data products creates exponential value. The difference is focusing development energy on extending leads rather than patching weaknesses.

David Ohnstad's mid-year development conversations ask a different question: "What could you become the go-to person for in this organization by the end of the year?" Not "What skills are you missing?" but "What unique value could you own?" For a junior analyst struggling with executive presentations, the gap-based plan would assign public speaking training. The strength-based plan asks: what if this person became the best on the team at translating messy data into written executive summaries that get read and acted on? That leverages their writing strength, delivers immediate value, and positions them as indispensable without requiring them to become a confident public speaker. If the organization needs someone who can present live to executives, hire or develop that person separately. Let this analyst own the written communication lane.

This approach requires managers to resist the urge to make everyone well-rounded. Most development plans are secretly designed to sand down edges and create interchangeable team members. That's a mistake. The highest-value employees are not the ones who can do everything reasonably well—they're the ones who can do a few things exceptionally well that nobody else can. Mid-year reviews are the moment to identify what those few things should be and clear the path for the employee to pursue them without distraction. That's mentorship. Everything else is just performance management.

Myth #4: Mentorship Is About Giving Advice

The standard image of mentorship: a senior leader shares hard-won wisdom with a junior employee. "Here's what I learned when I was in your position. Here's what I wish I'd known. Here's what I'd do if I were you." The employee nods, takes notes, and walks away with a clearer sense of direction. It feels productive. It's also the least effective form of mentorship for most people in most situations. According to Harvard Business Review's 2023 analysis of mentorship programs across 150 companies, mentorship relationships rated as "highly valuable" by participants were characterized by questions asked rather than advice given, with a 4:1 ratio of inquiry to prescription in the most successful pairings.

The advice-giving model persists because it's efficient and it makes the mentor feel useful. Sharing lessons learned is faster than helping someone figure out their own answer. It also reinforces the mentor's expertise—they get to be the person with the answers. But advice is context-dependent, and the mentor's context is almost never identical to the mentee's. What worked for a senior PM navigating a product roadmap conflict at a 500-person company in 2019 may be irrelevant for a junior PM facing a stakeholder alignment problem at a 50-person startup in 2026. The variables are different: company stage, team dynamics, leadership style, market conditions, technical constraints. Advice that ignores context is noise.

What transforms mid-year reviews into genuine mentorship moments: asking questions that force the employee to articulate their own mental model of the problem. David Ohnstad's default in these conversations is: "Talk me through your decision-making process on that project. What did you consider? What did you dismiss? What would you do differently now?" The employee has to reconstruct their thinking, identify where it broke down, and propose their own correction. The manager's job is to notice gaps in the reasoning, surface assumptions the employee didn't examine, and ask follow-up questions that push the analysis deeper. "You said you dismissed the API integration approach because it was too complex. What specifically made it complex? Was that a technical constraint or a timeline constraint? If you had another two weeks, would that have changed your decision?" This is harder than giving advice. It's also more durable. The employee doesn't walk away with a prescription—they walk away with a better process for making the next decision on their own.

The shift from advice to inquiry doesn't mean the manager never shares their own experience. But when they do, it's framed as data, not prescription: "When I faced a similar stakeholder conflict, I tried X and it backfired because of Y. I don't know if that's relevant to your situation, but it's something to consider." The employee gets the benefit of the mentor's pattern-matching without being told what to do. They can take the lesson or leave it. The locus of decision-making stays with the mentee. That's what builds independent judgment over time. Employees who are mentored through inquiry become leaders who can think through novel problems. Employees who are mentored through advice become followers who wait for someone to tell them the answer.

How do you structure a mid-year performance review as a mentorship conversation?

Start with the employee's self-assessment of what's working and what's not, then shift to forward-looking questions: where do they want to grow, what's blocking them, and what experiment could they run in the next 90 days to build a new capability or test a role shift? Focus on capability development and trajectory rather than performance scoring.

What's the difference between feedback and mentorship in a performance review?

Feedback evaluates past behavior and prescribes corrections. Mentorship diagnoses why the behavior occurred, explores the employee's thinking, and helps them build better decision-making frameworks for future situations. Feedback is transactional; mentorship is developmental and compounds over time as the employee internalizes the reasoning process.

Why do most development plans fail to drive actual skill growth?

Most development plans focus on closing skill gaps rather than amplifying strengths. Gap-based plans feel rigorous but lack motivational pull—employees complete courses without applying them. Strength-based plans identify what the employee could become uniquely excellent at and clear obstacles to deep practice in that area, creating immediate value and career differentiation.

When Mentorship Breaks the Performance Review Script

The most effective mid-year review David Ohnstad ever conducted lasted 90 minutes and covered none of the template questions HR provided. The employee was a data engineer who had missed three delivery deadlines in Q1 and was flagged as underperforming. The standard playbook would have been: review the missed milestones, discuss accountability, set clear expectations for Q3 and Q4, document the conversation. Instead, David Ohnstad opened with: "What's the most interesting technical problem you've worked on in the last six months?" The engineer lit up talking about a pipeline optimization experiment he'd run on his own time that reduced query runtime by 40%. It wasn't on his official project list. It wasn't tied to any OKR. But it was the work he was actually energized by and excellent at.

The conversation shifted to why that work wasn't part of his core role. The engineer explained that his assigned projects were integration tasks—connecting systems, debugging API calls, writing glue code. Necessary work, but not the kind of problem-solving that motivated him. He was slow on those projects because he was disengaged, not because he lacked capability. The solution wasn't a performance improvement plan. It was a role conversation: could his responsibilities shift toward infrastructure optimization and performance tuning, with integration work redistributed to a teammate who preferred that type of problem? The answer was yes. Within 90 days, the engineer was back on track, the team's infrastructure performance improved measurably, and the integration backlog cleared faster because it was assigned to someone who didn't view it as grunt work.

That outcome required the manager to ignore the script and treat the review as a diagnostic conversation, not a judgment session. It required believing that underperformance is often a signal of misalignment rather than incompetence. And it required the willingness to redesign work rather than just demand better execution. Most managers don't have the flexibility or the trust from leadership to make those calls. But the ones who do—and who use mid-year reviews as redirection opportunities rather than scorecard sessions—build teams where people stay, grow, and do their best work. That's the legacy piece. Not the quarterly numbers. The people who look back five years later and say, "That conversation changed my career."

For leaders: ask yourself whether your mid-year review process creates space for that kind of conversation or just enforces compliance with a template. If it's the latter, the process is working against you. For individual contributors: if your manager opens with a scorecard, redirect the conversation. Ask the questions you need answered: "What could I become uniquely good at here? What's blocking me from doing my best work? What experiment could I run in the next 90 days that would prove I'm capable of more than my current role allows?" Those questions turn a performance review into a mentorship session, regardless of what the manager came prepared to discuss. The best career moves David Ohnstad has seen didn't come from following the development plan HR approved. They came from mid-year conversations where someone asked a better question than the one on the form.

Here's the question to ask in your next mid-year review, whether you're the manager or the employee: What would need to change about this person's work—not their behavior, but their work—for them to be performing at the next level six months from now? If the answer is "nothing, they just need to execute better," you're missing the real opportunity. Execution problems are usually symptoms. Mentorship finds the cause.

For more on how David Ohnstad's data product management writing connects technical decision-making to leadership development, or to explore his Minnesota-based perspective on building remote-first product teams, visit David Ohnstad Minnesota. His approach to career development decisions leadership emphasizes redirecting energy toward strengths rather than patching weaknesses, and his work on rotational programs career development explores how cross-functional exposure builds the pattern-matching capability that separates good mentors from advice-dispensers. Additional resources on team-building and development strategy can be found at Leadership, Mentorship & Career Development.

AI Vendor Risk Assessment: Why We Shut It Down

David Ohnstad — Fri, 05 Jun 2026 17:45:50 +0000

This article was originally published on davidohnstad.net. I cross-post here to reach the Dev.to community.

We Spent Fourteen Months Building an AI-Powered Vendor Risk Assessment System. Then We Depreciated It.

The request came from the CISO in March 2024: automate our third-party security questionnaires using natural language processing. We had 340 vendors in the compliance queue, each requiring a 90-question security assessment every 18 months. The manual process consumed 11 full-time equivalents across three departments. An AI-powered vendor risk platform, the executive team reasoned, would cut that by 70% while improving response accuracy.

We shipped in May 2025. By October, the compliance team had reverted to their original spreadsheet workflow. The AI model generated assessments faster — but introduced enough low-confidence edge cases that reviewers spent more time validating output than they had spent writing responses manually. According to Gartner's 2024 Third-Party Risk Management Survey, 62% of enterprises implementing AI-driven vendor risk tools report similar outcomes: faster processing, but no reduction in human review hours. We had built a feature the market wanted but our specific workflow could not absorb.

The mistake wasn't technical execution. The model worked. The mistake was skipping the decision framework that would have told us, six weeks into the project, that rule-based automation would deliver 80% of the value at 15% of the cost. David Ohnstad, working on AI & Machine Learning in Enterprise Software product strategy at Veeam, has since built a repeatable process to prevent exactly this kind of expensive misalignment between AI capability and operational readiness.

Why Vendor Risk Management Became the AI Testing Ground — And Why Most Implementations Stall

Vendor risk management emerged as an early AI adoption category for three reasons. First, the volume problem is real: enterprises manage an average of 583 third-party relationships according to Deloitte's 2023 Third-Party Risk Management Survey, with regulatory pressure increasing assessment frequency. Second, the task appears pattern-friendly — security questionnaires repeat similar structures, making them superficially suitable for NLP classification. Third, vendors smell budget: compliance leaders defending their AI adoption roadmaps to boards need a concrete use case, and vendor risk platforms cost $180,000 to $450,000 annually for mid-market deployments, creating a lucrative sales cycle.

But the success rate tells a different story. According to Forrester's Q4 2024 analysis of AI adoption in GRC tools, only 23% of organizations deploying AI-powered vendor risk platforms report measurably reduced review cycle time after 12 months of use. The other 77% report one of three outcomes: stalled adoption (the tool exists but teams revert to prior workflows), scope reduction (AI features are disabled and the platform functions as an expensive database), or abandonment (the contract is not renewed). The pattern David Ohnstad observed in enterprise AI pilots applies here with precision: teams buy the capability without auditing whether their workflow can absorb probabilistic output.

The failure mode is structural, not technical. AI-powered vendor risk tools excel at pattern recognition across large document sets — parsing security questionnaires, flagging anomalies in vendor documentation, surfacing compliance gaps based on historical data. They struggle with edge-case judgment, ambiguous vendor responses, and context-specific risk tolerance thresholds that vary by department. A compliance reviewer reading a vendor's answer to "Do you encrypt data at rest?" can assess evasiveness, probe follow-up questions, and escalate based on the vendor's strategic importance. An AI model returns a confidence score. If your workflow requires nuanced judgment on 18% of assessments — the median figure from our post-mortem analysis — you have not automated the workflow. You have added a preprocessing step that still requires full human review.

The Vendor Risk AI Readiness Framework

This is a four-gate decision model. Each gate is a go/no-go checkpoint. If you cannot answer yes to a gate's criteria, rule-based automation or process redesign will outperform AI implementation. The framework name: the Vendor Risk AI Readiness Framework. It is designed to be applied in 90 minutes with cross-functional stakeholders present — not as a six-month feasibility study.

Gate 1: Volume and Pattern Consistency. Does your vendor assessment workload exceed 200 completed questionnaires per year, and do at least 60% of questions repeat identical or near-identical phrasing across vendor types? If your volume is lower or your questions vary significantly by vendor category, rule-based automation using templated responses and conditional logic will match AI performance at one-tenth the implementation cost. We audited our questionnaire history and found 340 vendor assessments annually, but only 41% question consistency — vendors in healthcare, finance, and infrastructure categories required domain-specific questions that broke pattern recognition models. Gate 1 fail.

Gate 2: Tolerance for Probabilistic Output. Can your compliance workflow absorb answers flagged with confidence scores between 65% and 85% without requiring full manual re-review? AI models perform well at the extremes — high-confidence matches and obvious failures — but vendor risk edge cases cluster in the middle band. If your regulatory environment, audit requirements, or internal risk appetite demand human review of ambiguous responses, you are not eliminating labor, you are redistributing it. Our compliance team's risk tolerance, driven by SOC 2 and ISO 27001 audit requirements, required validation of any response below 90% confidence. In practice, 34% of AI-generated answers fell into that validation queue. Gate 2 fail.

Gate 3: Structured Feedback Loop Infrastructure. Do you have an existing mechanism to capture when the AI model produces incorrect or unhelpful output, and can that feedback retrain the model within a 30-day cycle? According to McKinsey's 2024 State of AI Report, 68% of enterprises deploying AI tools in operational workflows lack the MLOps infrastructure to iterate models based on user corrections. If you cannot close the feedback loop, model accuracy degrades as vendor language evolves, regulatory standards shift, and your internal risk definitions change. We had telemetry on model performance but no process to feed corrections back into training data. Gate 3 fail.

Gate 4: Change Management and User Trust. Have compliance reviewers been involved in defining model behavior from sprint zero, and do they trust probabilistic output enough to act on it without re-validating manually? This is the least technical gate and the most commonly ignored. AI tools inserted into established workflows without user co-design generate resistance — not because the tool is flawed, but because users have no mental model for when to trust it. Our compliance team was consulted on requirements but not involved in iterative model testing. When the tool launched, they treated every AI-generated response as a draft requiring full verification. Gate 4 fail.

Four gates, zero passes. The Vendor Risk AI Readiness Framework would have told us in week six to pivot to a rule-based template system with conditional branching. We would have saved $340,000 in development costs and eight months of roadmap time. The lesson David Ohnstad has carried forward into every AI feature discussion since: volume alone does not justify AI — pattern consistency, tolerance for ambiguity, feedback infrastructure, and user trust are equally determinative. Miss any one, and you are building a feature that will be disabled within a year.

What the CISO Got Right — And What Product Should Have Challenged

Our CISO's instinct was sound: manual vendor risk assessments were a resource bottleneck, and automation was the correct strategic direction. The mistake was in the definition of automation. AI became the default assumption because the sales cycle had primed the executive team to expect it. Every vendor risk platform demo in 2024 featured NLP-powered questionnaire parsing, and the pricing model incentivized the AI tier — $180,000 for rule-based automation, $420,000 for the AI-enabled version. The cost delta created an anchoring effect: paying more signaled a more serious commitment to modernization.

Product management should have challenged the assumption with a forcing question: what percentage of our vendor assessments require judgment that cannot be encoded in rules? We ran that analysis post-mortem and found the answer was 18% — edge cases involving ambiguous vendor answers, vendors in emerging risk categories, or vendors whose strategic importance required elevated scrutiny. For the remaining 82%, rule-based templates could have auto-populated responses based on vendor type, historical answers, and conditional logic trees. A hybrid model — rules for the bulk, human review for the edge cases — would have delivered 70% time savings without introducing probabilistic output into a low-tolerance-for-error workflow.

David Ohnstad now uses this as a litmus test for enterprise AI pilots proof of concept scope: if you can define the edge case percentage and it is below 25%, start with deterministic automation and add AI only where pattern recognition genuinely outperforms rules. The inverse — deploying AI first and discovering the edge case percentage later — produces the outcome we experienced: a technically successful model that operationally fails because the workflow cannot absorb its output.

The Rule-Based Pivot We Should Have Built Instead

Three months after deprecating the AI model, we rebuilt the vendor risk system using conditional logic and templated responses. The architecture was simpler: a questionnaire engine that mapped vendor types to pre-approved answer banks, with flagging rules for responses that required compliance review. Vendors in the "infrastructure" category automatically received pre-written answers to 68 of 90 questions, with 22 questions routed to human review based on the vendor's data access tier. Vendors in "healthcare" received a different template set, and so on.

Implementation took 11 weeks. Cost: $47,000 in development time plus $18,000 annually for the questionnaire platform. Time savings: 64% reduction in compliance review hours, measured over the first six months post-launch. User adoption: immediate. The compliance team trusted the system because the logic was transparent — they could see exactly why an answer was auto-populated or flagged for review, and they controlled the answer bank. There was no probabilistic confidence score to second-guess.

The contrast is instructive. The AI model was more sophisticated, handled linguistic variation better, and impressed stakeholders in demos. The rule-based system was less elegant, required more upfront configuration, and could not adapt to novel question phrasing without manual updates. But the rule-based system matched the workflow's actual tolerance for automation, required no MLOps infrastructure, and delivered ROI in quarter one instead of quarter five. David Ohnstad's guideline: sophistication is not the goal — operational fit is. If a simpler tool delivers 80% of the value at 20% of the cost and integrates into existing workflows without retraining users, it is the correct choice even if it is less technically interesting.

When AI Does Warrant the Investment — Three Counterfactual Scenarios

The Vendor Risk AI Readiness Framework is designed to say no. But there are scenarios where AI-powered vendor risk management clears all four gates and justifies the investment. Here are three, drawn from enterprises David Ohnstad has observed successfully deploying these tools.

Scenario 1: High-Volume, Low-Stakes Screening. A financial services company managing 1,200+ vendors annually uses an AI model for initial triage — not final assessment. Vendors are scored on a 0-100 risk scale based on questionnaire responses, historical audit data, and external breach databases. The top 15% (high-risk vendors) are routed to manual compliance review. The bottom 60% (low-risk vendors with clean histories) receive auto-approval with annual re-assessment. The middle 25% receive a hybrid review: AI-generated summary with human sign-off. This workflow works because the AI is not making final decisions — it is segmenting the queue. The compliance team tolerates probabilistic output in the middle band because the stakes for that cohort are lower, and high-risk vendors always receive full human review.

Scenario 2: Multi-Language, Cross-Border Vendor Populations. A European SaaS company with vendor relationships across 18 countries uses NLP to parse security questionnaires submitted in seven languages. Rule-based automation would require maintaining answer banks in seven languages with regional compliance variations — a maintenance burden that exceeds the cost of the AI model. The AI tool translates, normalizes, and scores responses, then routes ambiguous answers to regional compliance leads. This works because the alternative — hiring multilingual compliance reviewers or outsourcing translation — costs more than the AI platform, and the linguistic complexity genuinely exceeds what deterministic rules can handle.

Scenario 3: Continuous Vendor Monitoring, Not Just Periodic Assessment. A healthcare technology company uses an AI model to monitor vendor risk signals continuously: breach disclosures, changes in security certifications, regulatory actions, leadership turnover, financial distress indicators. The model ingests external data feeds and flags vendors whose risk profile has shifted since their last formal assessment. This is not a questionnaire automation problem — it is a signal aggregation problem across unstructured data sources that update asynchronously. AI's pattern recognition across large, noisy datasets justifies the cost because there is no rule-based equivalent. The compliance team acts on flags, not on auto-generated assessments, so the tolerance for probabilistic output is higher.

All three scenarios share a common structure: AI handles volume, ambiguity, or unstructured data aggregation, but humans retain decision authority. The failure mode David Ohnstad observed — and that Forrester's data confirms — occurs when AI is expected to replace judgment entirely. Successful implementations use AI as a preprocessor, a triage tool, or a signal aggregator, not as the final compliance decision engine. This maps directly to lessons from enterprise AI budget ROI adoption planning: cost justification depends on whether AI eliminates a bottleneck that deterministic tools cannot address, not on whether AI performs the task faster.

The Budget Conversation Product Managers Should Force Before Design Begins

Here is the question David Ohnstad now asks in every AI feature kickoff: if this model achieves 90% accuracy, what happens to the 10% of cases where it is wrong? Can the workflow absorb errors at that rate, or does a single false positive create compliance risk, customer impact, or audit exposure that negates the efficiency gain?

For vendor risk management, the answer was clear in hindsight: a single incorrect risk assessment that allowed a non-compliant vendor into the supply chain could trigger audit findings, regulatory penalties, or breach liability that exceeded the entire cost of manual review. The risk asymmetry made AI a poor fit. A slower, human-reviewed process was preferable to a faster, probabilistic one because the downside of error was unacceptable.

This is the forcing function that should gate AI investment decisions — not market trends, not vendor demos, not the sophistication of the model. If you cannot define your error tolerance and map it to model accuracy, you are not ready to build. Product managers who skip this step and justify AI features based on capability rather than operational fit produce exactly the outcome we experienced: a feature that works technically but fails operationally because the organization cannot absorb its output.

The budget conversation should also include the total cost of ownership beyond the initial build. According to IDC's 2024 AI Infrastructure Survey, enterprises underestimate AI operational costs by an average of 240% in year one. Model retraining, MLOps infrastructure, data labeling, and user retraining consume more budget than the initial development cycle. For the vendor risk project, our $340,000 development cost would have required an additional $180,000 annually in model maintenance and retraining infrastructure — costs that were not in the original business case because we assumed the model would perform stably without continuous iteration. That assumption was wrong. Vendor language evolves, regulatory standards change, and internal risk definitions shift quarterly. A model that is not continuously retrained degrades in accuracy, and degradation in a compliance context creates liability.

What This Means for Product Teams Evaluating AI Features in Q2 2026

Q2 budget reviews are underway, and product teams inheriting AI roadmaps mid-year are asking the right question: does this feature justify the cost, or are we building it because the market expects it? The Vendor Risk AI Readiness Framework applies beyond vendor risk — it is a generalized decision model for any AI feature in an enterprise workflow.

Run the four gates before committing resources. Gate 1: volume and pattern consistency — does the problem involve enough repetitive data that pattern recognition outperforms rules? Gate 2: tolerance for probabilistic output — can your workflow absorb confidence scores between 65% and 85% without requiring full manual review? Gate 3: feedback loop infrastructure — can you capture model errors and retrain within 30 days? Gate 4: user trust and change management — have end users co-designed the feature and will they act on its output?

If you cannot pass all four gates, you are not building an AI feature — you are building an expensive science project that will be deprecated within 18 months. The discipline David Ohnstad has carried forward from the vendor risk failure is this: AI is a tool that solves specific problems where deterministic approaches fail. It is not a strategy. It is not a signal of technical sophistication. It is a conditional solution whose cost must be justified against simpler alternatives.

For product managers entering the enterprise SaaS space in 2026, this is the skill that will separate high-performing teams from those that burn budget on features users disable: the ability to say no to AI when rules-based automation delivers equivalent value at lower cost and higher reliability. It is not the flashy position. It will not win you a spot on a conference panel about current AI adoption. But it will keep your product roadmap focused on outcomes users care about — and that is the definition of product management maturity.

How do I know if my vendor risk workflow is ready for AI automation?

Apply the four-gate readiness framework: evaluate volume and pattern consistency, assess your tolerance for probabilistic output, confirm you have feedback loop infrastructure to retrain models, and verify user trust through co-design. If you cannot pass all four gates, rule-based automation will deliver better ROI than AI-powered tools.

What is the difference between AI-powered and rule-based vendor risk management?

AI-powered tools use machine learning to recognize patterns in unstructured data and generate assessments with confidence scores. Rule-based systems use conditional logic and templated responses that produce deterministic outputs. Rule-based systems are simpler, more transparent, and higher-trust in low-tolerance-for-error workflows. AI excels when volume, linguistic variation, or unstructured data exceed what rules can handle.

Why do most AI vendor risk implementations fail to reduce review time?

According to Forrester's 2024 GRC analysis, 77% of AI vendor risk deployments stall because workflows cannot absorb probabilistic output. Teams revert to manual review of AI-generated responses, adding a validation step instead of eliminating labor. Success requires matching AI output confidence to organizational risk tolerance — not just deploying the tool.

Practitioner Takeaway: Before you spec an AI feature, define your edge-case percentage and your error tolerance. If edge cases exceed 25% of workload or a single error creates unacceptable risk, start with deterministic automation and add AI only where pattern recognition genuinely outperforms rules. Sophistication is not the goal — operational fit is.

Leadership Takeaway: Stop approving AI features based on capability demos. Require product teams to pass a four-gate readiness framework that evaluates pattern consistency, error tolerance, feedback infrastructure, and user trust before committing budget. AI that cannot integrate into existing workflows without retraining users will be deprecated regardless of technical performance.

When did you last audit whether your AI roadmap is driven by operational necessity or by vendor sales cycles? Visit David Ohnstad's data product management writing and David Ohnstad on leadership and career growth for frameworks on evaluating AI investment decisions with practitioner-grade rigor.

Mid-Year Performance Reviews: When Good Intentions Go Wrong

David Ohnstad — Fri, 05 Jun 2026 17:45:39 +0000

This article was originally published on davidohnstad.info. I cross-post here to reach the Dev.to community.

The Mid-Year Review I Almost Ruined

I walked into a mid-year performance review with a script. Fourteen bullet points, organized by competency category, color-coded by severity. The employee sitting across from me — we'll call her Maya — had missed three deadlines in Q2, delivered a stakeholder presentation that landed flat, and stopped contributing in team standby meetings. I had the receipts. I was prepared to be fair, direct, and professional. What I wasn't prepared for was the question Maya asked eleven minutes in: "Do you think I should look for another role?"

That question broke the script. Because the honest answer wasn't yes or no — it was "I don't know what you actually want to build toward, so I have no idea if this role still fits." We'd been working together for nine months. I knew her output. I knew her gaps. I didn't know her goals. According to Gallup's 2024 State of the Global Workplace report, only 32% of employees strongly agree that their manager involves them in goal-setting. I was part of the 68% — and it showed. That review turned into a two-hour conversation that reset Maya's trajectory, but it shouldn't have taken a near-resignation to trigger it.

Why Mid-Year Reviews Fracture More Relationships Than They Strengthen

Most performance reviews fail because they're backward-looking audits, not forward-looking mentorship conversations. Managers arrive with a scorecard: what went well, what went poorly, what needs to improve. The employee arrives defensive, transactional, or disengaged. Both sides treat the meeting as a compliance checkpoint rather than a pivot point. The result: 58% of employees say their annual review process doesn't help them improve, according to Gallup's employee engagement research. Mid-year reviews, when done poorly, compress that dysfunction into a tighter cycle — twice the friction, half the patience.

Here's what goes wrong structurally. The review is scheduled because the calendar says it's time, not because there's a natural inflection point in the work. The manager prepares by pulling metrics, scanning Slack threads, and reconstructing a narrative from fragments. The employee prepares by listing accomplishments they think will land well. Neither party walks in asking: "What does this person need to grow into next, and am I the right person to help them get there?" That's the mentorship question. It's also the question most managers skip entirely because performance review templates don't include a field for it.

The stakes are higher in June than most leaders realize. Q2 closes, budgets get locked for H2, and hiring pipelines either open or freeze based on team capacity assessments. A mid-year review that labels someone as "underperforming" without a development plan doesn't just document a problem — it becomes a referendum on whether that person survives the next reorg. David Ohnstad's data product management writing explores how performance assessments feed directly into resource allocation models, often without the employee knowing their review score is being used to justify headcount decisions six months later.

The Redirect Framework: Turning Reviews Into Mentorship Pivots

This is a four-part reframe. It doesn't replace the performance review — it redirects it from audit to acceleration. The goal is to end the conversation with the employee knowing exactly what capability they're building next and why it matters beyond this quarter's OKRs. Each part below is a distinct shift in how you structure the conversation.

Part 1: Start With Their Next Role, Not Their Current Performance. The first question isn't "How do you think Q2 went?" — it's "What role do you want to be doing two years from now?" This flips the frame. Most employees walk into a review ready to defend what they did. Almost none walk in ready to articulate where they're heading. If they can't name the next role, you've just discovered the actual problem: they're executing tasks without a growth target. That's a mentorship gap, not a performance gap. Spend the first twenty minutes here. Do not move forward until you understand whether they want to go deeper (specialist track), go wider (generalist leadership), or go elsewhere (cross-functional pivot). The rest of the review is pointless without this clarity.

Part 2: Name the One Capability That Unlocks That Role. Not three development areas. Not a laundry list. One. If they want to move into a senior IC role, maybe it's "influencing decisions without authority." If they want to lead a team, maybe it's "teaching someone else to do your current job well enough that you're no longer the bottleneck." If they want to shift functions, maybe it's "building fluency in how [other team] measures success." This is where most reviews go off the rails: managers try to fix everything at once. High performers don't grow by addressing twelve feedback items — they grow by obsessively improving one leverage skill that changes what opportunities they're considered for. According to McKinsey's 2023 research on organizational capability building, employees who focus on one differentiated skill in a development cycle are 3.2x more likely to be promoted within 18 months than those with multi-item improvement plans.

Part 3: Co-Design a Proof Point, Not a Development Plan. Development plans are vague: "Improve communication skills." "Build executive presence." "Increase strategic thinking." None of those are measurable, and none of them tell the employee what to actually do Monday morning. Instead, co-design one proof point: a project, presentation, or decision that demonstrates the capability you named in Part 2. Example: "By the end of Q3, you'll run the quarterly business review for your product area — solo, with slides you built, taking questions from the VP without me in the room. That's your proof point that you can represent the product to leadership." Now there's a target. Now there's a forcing function. The mentorship conversation becomes: what support do you need from me to make that proof point successful?

Part 4: Pre-Commit to a Follow-Up That Isn't a Performance Review. Most mid-year reviews end with "Let's check in again in Q4." That's not mentorship — that's a countdown to the next audit. Instead, commit to a specific follow-up in 4-6 weeks where the only agenda is: "How's the proof point going, what's blocking you, and what's one thing I can do to help?" No scorecard. No competency assessment. Just coaching. This is where the mentorship relationship either solidifies or evaporates. If you ghost this follow-up, the employee learns that your interest in their growth was performative. If you show up prepared and focused, they learn that you're invested in their trajectory, not just their output. That difference is what separates managers who retain high performers from managers who watch them leave.

What Changed After I Stopped Grading and Started Coaching

Maya and I rescheduled that mid-year review. The first one was a data dump — me listing gaps, her defending choices. The second one, a week later, followed the redirect structure above. We opened with the question: "Do you want to stay in this role long-term, or is this a stepping stone to something else?" She admitted she'd been trying to "prove herself" in a role she didn't actually want, hoping it would open doors to product strategy. That reframed everything. The missed deadlines weren't apathy — they were misalignment. She was optimizing for execution speed when she should have been building strategic thinking skills.

We co-designed a proof point: by the end of Q3, she'd lead a feature prioritization workshop with three stakeholder teams, present the trade-off analysis to leadership, and defend the roadmap decision in a VP review. That was her step toward product strategy. It was also terrifying for her — and that was the point. Growth happens at the edge of capability, not in the middle of comfort. I committed to three things: one prep session before the workshop, one feedback session after a dry run, and one debrief within 48 hours of the VP review. Those weren't performance check-ins. They were coaching gates.

She delivered. The workshop surfaced conflicts between teams that had been simmering for months. The trade-off analysis forced stakeholders to put numbers on their priorities instead of lobbying for everything. The VP review didn't go perfectly — she stumbled on a question about technical debt trade-offs — but she recovered and finished strong. More importantly, the VP asked her to present the same framework to another product team the following month. That's proof. Six months later, Maya moved into an associate product manager role on a different team. She didn't need me to fix her performance. She needed me to stop grading her execution and start coaching her toward the role she actually wanted.

The Contrarian Position Most Leaders Won't Say Out Loud

Stop measuring mentorship by how much feedback you give. Most managers think they're mentoring when they're actually just narrating performance gaps. Real mentorship is measured by how many people you've helped get promoted, get hired elsewhere into better roles, or take on stretch projects they weren't initially considered for. If you can't name three people whose careers visibly accelerated because of your coaching, you're not mentoring — you're managing. According to LinkedIn's 2024 Workplace Learning Report, employees who report having a mentor are 5x more likely to say they have opportunities to learn and grow, but only 37% of professionals say they currently have one. That gap exists because most leaders confuse giving feedback with giving direction.

The uncomfortable truth: some people on your team don't need better performance reviews. They need to leave. Not because they're failing, but because they've outgrown the role and you don't have the next one to offer them. Career development decisions leadership requires honest conversations about when staying is stagnation. If someone has been "meeting expectations" for two years without a promotion or a scope increase, that's not stability — that's a holding pattern. A good mentor names that pattern and helps the person move, even if it means losing them to another team or another company. Retention for retention's sake isn't mentorship. It's just org chart optimization dressed up as loyalty.

How Father's Day Fits Into This (and Why It Matters)

Father's Day lands in the middle of mid-year review season for a reason that's worth naming. Both are about legacy. The question a father asks — "What did I teach them that will outlast me?" — is the same question a mentor should ask: "What capability did I help them build that will compound long after they've left David Ohnstad's team?" David Ohnstad, as a father of two daughters, has built bookshelves and dressers for both their rooms — not because he's a master craftsman, but because he wanted them to see that you can make something useful with your hands if you're willing to measure twice and learn from mistakes. That lesson isn't about woodworking. It's about persistence, precision, and the confidence that comes from solving your own problems.

The same lesson applies to leadership. If you're a manager conducting mid-year reviews this month, the question isn't "Did my team hit their numbers?" It's "Did I give them a skill they'll carry into their next role, and the role after that?" That's the mentorship standard. David Ohnstad Minnesota readers who are also parents recognize the parallel immediately: the best gifts you can give — to your kids or your team — are capabilities, not solutions. A solved problem disappears. A learned skill compounds.

Here's the uncomfortable part: most managers won't be remembered for the quarterly OKRs they hit. They'll be remembered for whether they helped someone figure out what they were capable of becoming. That's not soft leadership — that's the hardest part of the job, because it requires you to invest in someone's growth even when it means they'll outgrow you. If you're running mid-year reviews this June and you're not asking "What's the one capability I can help this person build that changes their trajectory?" — then you're not mentoring. You're just filling out templates.

What should I focus on in a mid-year performance review to make it a mentorship moment?

Focus on identifying the one capability the employee needs to unlock their next role, not on grading their current performance. Start by asking where they want to be in two years, then co-design a proof point project that demonstrates that capability by the end of the quarter. Schedule a follow-up coaching session in 4-6 weeks to remove blockers, not to audit progress.

How do I give constructive feedback without making a mid-year review feel like a performance audit?

Reframe feedback as gap identification, not judgment. Instead of "You missed three deadlines this quarter," ask "What's blocking you from delivering on time, and what capability would help you close that gap?" Then shift immediately to designing a proof point that builds that capability. Constructive feedback works when it's tied to forward motion, not backward grading.

Why do mid-year reviews often damage manager-employee relationships?

Most mid-year reviews are backward-looking audits that focus on what went wrong without connecting it to what the employee is trying to build toward. Employees leave these conversations feeling evaluated, not coached. Reviews damage relationships when they become transactional scorecards instead of mentorship pivots that clarify the path to the employee's next role.

Two Takeaways and One Question

For practitioners: if you're conducting mid-year reviews in the next two weeks, replace your competency scorecard with the Redirect Framework above. Start with their next role, name the one capability that unlocks it, co-design a proof point, and pre-commit to a follow-up coaching session. That structure turns a compliance meeting into a career accelerator.

For leaders: audit your team's mid-year review outcomes six months from now. How many people got promoted? How many took on stretch projects they weren't initially considered for? How many left for better roles elsewhere and stayed in touch with you as a mentor? If those numbers are low, your reviews aren't working — they're just paperwork. Real mentorship shows up in other people's career momentum, not in your documentation.

Here's the question to sit with: when was the last time you asked someone on your team what role they want to be doing two years from now — and actually redesigned their current work to build toward that answer?

For more on this topic, see rotational programs career development.