DEV Community: Chad Dyar

Why I stopped scoring performance and started asking about it

Chad Dyar — Sat, 05 Sep 2026 22:44:37 +0000

Twenty years running sales enablement programs taught me that performance reviews miss the person almost every time. I wrote Performance Is Personal after watching one more coaching framework skip the part where someone actually has to change, not just get scored. The book walks through what real behavior change looks like in practice, with the awkward middle included. If you manage people, or you are the one being managed, the ideas here might save you a few bad quarters. The awkward middle is where the work actually happens.

HomeGrown vs Gardenize comparison page

Chad Dyar — Sat, 05 Sep 2026 22:44:33 +0000

Gardenize tracks what you planted and where it needs care. HomeGrown starts from what's actually ripe in your garden right now and turns it into a recipe you can cook tonight. Different halves of the same problem. One is a planner, the other is a cook. I built HomeGrown because I kept staring at tomatoes on my counter wondering what to do with them before they went bad. The app tells you what to make with what you have, not what you should have planted six months ago. Full comparison: thehomegrown.app/gardenize-alternative

How to Talk to Humans

Chad Dyar — Thu, 27 Aug 2026 23:22:31 +0000

Why Your Best Code Won't Matter If You Can't Explain It

I spent two years watching brilliant engineers tank career conversations. Not because they weren't smart. Because they tried to translate their intelligence directly into words, and somewhere between their brain and the other person's ear, everything got scrambled.

One of them built a system that cut database query time by 68%. He got into a room with a non-technical stakeholder to pitch for resources. Thirty seconds in, he was deep in indexing strategy. The stakeholder checked out. The project didn't get funded.

Here's what happened: he was speaking to someone else's context, not the person in front of him.

The gap between knowing something and being able to explain it to a human who doesn't share your frame of reference is not a soft skill. It's a hard constraint on how far your work travels. It affects whether your ideas get adopted. Whether you get promoted. Whether you can influence decisions that matter. Whether anyone actually understands what you built and why it matters.

Most engineers I've worked with treat communication like a tax on "real work." You finish the thing, then you have to go explain it to people who don't get it. Tolerate their questions. Try not to be frustrated that they need it spelled out.

That's backward.

Explaining something to someone who doesn't speak your language is a skill. A learnable one. Not something you're born with or not. It's not about dumbing anything down. It's about meeting someone in their world first, building a shared understanding, then moving together toward the technical reality.

The difference between a mediocre explanation and one that sticks is usually this: you stopped assuming what the other person knows, and you started assuming what they care about. You built a bridge from their problem to your solution instead of just describing the solution and hoping they could figure out the bridge on their own.

I wrote "How to Talk to Humans" because I kept seeing the same pattern across teams. Engineers who could architect systems that scale to millions of requests, but couldn't articulate to their manager why that architecture mattered. Product people who understood the feature but couldn't explain it to customers in a way that made sense. Leaders who had the right strategy but couldn't bring people along because the words didn't land.

The book is built on one core idea: communication is not decoration on top of competence. It's a tool that makes your competence visible, transferable, and valuable to other people. And like any tool, it has techniques.

The chapters walk through real scenarios. How to explain something technical to someone non-technical without losing precision. How to listen for what someone actually needs to hear, not what you think they should know. How to move a conversation from confusion to clarity without sounding like you're simplifying. How to know when you're speaking and when you should shut up and listen.

None of this is theory. It's all grounded in conversations that actually happened, mistakes I watched happen, and what changed when people started thinking about communication the way they think about code: as a problem to solve, with constraints, patterns, and things that work better than other things.

If you've ever felt like your work didn't get the credit it deserved, or you watched someone less capable than you move up because they communicated better, or you've been in a room where everyone nodded but nobody understood what you said, this book is for you.

You already know how to solve hard problems. This teaches you how to make sure other people understand the solution.

"How to Talk to Humans" is available now on Amazon. https://www.chadtdyar.com/books/how-to-talk-to-humans?utm_source=devto&utm_medium=community&utm_campaign=devto-20260827-howtotalktohuma

A sales agent lied to my database, and the test caught it before a buyer did

Chad Dyar — Wed, 19 Aug 2026 16:58:33 +0000

I run two sales agents in production now. InboxCopilot reads inbound email and qualifies leads. EnrichmentMessenger takes a CSV of prospects and writes first-touch messaging for the ones worth touching. Both of them write to the same attribution schema, a Postgres setup where every agent action logs as a touchpoint and gets a capped share of revenue credit when a deal closes.

Before either agent touched a real inbox or a real CSV, I ran them cold. Skill file verbatim as the system prompt, JSON Schema output contract, AJV validation on every response, zero retries, zero coaching. If the model can't follow its own instructions on the first try, the instructions are wrong, not the model.

InboxCopilot went 3 for 3. EnrichmentMessenger went 2 for 3.

Row 2 of the EnrichmentMessenger test was a prospect with no usable information. Not enough to enrich, not enough to message. The agent's job in that case is simple: skip it, log nothing, move on. Instead it returned a disposition of created, an empty enrichment payload, and a null message. That disposition is supposed to mean "this became a real sourced lead." Nothing about that row earned it. If that output had reached the database unexamined, it would have written a lead_created touchpoint for a lead that didn't exist in any meaningful sense, a phantom lead with a live attribution record.

Sourced pipeline is this product's cleanest number. It's the one metric that doesn't need a cohort comparison or a minimum sample size to mean something. A single phantom row poisons it quietly, because nothing about a bad created disposition looks wrong from the outside. The row exists. The lead exists. The number is just wrong.

I went in expecting a model failure. It wasn't. The skill file's disposition logic had a step-order conflict: a match-first read let the model assign created before the no-basis check ever ran. Given a row with almost nothing to work with, the instructions let the agent find something plausible to say instead of forcing it to say nothing. That's not a hallucination. That's a skill file that let ambiguity resolve toward action instead of toward silence.

The fix was to rewrite the whole disposition decision as one ordered tree with the no-basis check first, not as a set of conditions the model picks through in whatever order looks convenient. Ambiguity now resolves toward skipped_no_basis by default, with zero touchpoints attached, and only escalates toward a real disposition when the row actually earns it.

Re-run cold: EnrichmentMessenger 3 for 3, the same row now correctly skipped. InboxCopilot unchanged at 3 for 3. Six for six combined, no regression.

The schema carries a hard 50% cap on AI attribution credit regardless of how many touchpoints a deal accumulates, so a defect like this couldn't have inflated any single deal's number past that ceiling. But it could have created deals, and pipeline that was never real is worse than a capped number that's honest. The production assertion suite for the schema now runs 21 checks, all passing, and the ordered-tree pattern from this fix is the one I use for every disposition decision I write now, in this project and outside it.

If you want the receipts: schema and views at commit a231d16, the repo reaching shippable v1 shape at af7ec15, and the docs made fully accurate to the shipped code at 5d58f51.

No traction numbers here, because there aren't any yet. The kit launched with no case studies, and the plan was always to let the attribution data speak for itself once it exists. What I can show you today is that the test caught its own worst mistake before a real prospect ever touched it. If the "what can this actually claim" question interests you more than the pitch does, the methodology behind it is at stack.chadtdyar.com/deep-dive.

A cold run caught a bug in my own attribution layer. Here's what broke and how I fixed it.

Chad Dyar — Wed, 19 Aug 2026 14:23:29 +0000

I built two AI sales agents that share one attribution layer, and before I let either of them touch a real inbox, I ran them cold against a test dataset built specifically to catch the failure mode I was most worried about, the one I'd have been embarrassed to find after launch instead of before it.

The Agentic GTM Stack is InboxCopilot and EnrichmentMessenger, one shared attribution layer underneath both. Every action either agent takes gets logged as a touchpoint tied to a lead, and every touchpoint gets a capped, conservative slice of revenue credit: 50 percent ceiling, hard cap, written into the schema itself so no code path can quietly raise it later. The schema is plumbing. The reason the plumbing exists is the actual product. I did not want to ship an agent that could claim credit for something it did not do.

So the cold run was testing something narrower than whether the agents worked. It was testing whether the attribution layer would catch them when they didn't.

InboxCopilot passed clean, 3 for 3. EnrichmentMessenger did not. First pass came back 2 out of 3, and the failure was the kind I'd been dreading since I started writing the schema: a lead with no real work product behind it (null message, empty enrichment, nothing an agent had actually done) still got a disposition of created. That disposition is the one that emits a touchpoint. A phantom-sourced lead, credited like a real one.

Finding the actual defect

My first assumption was a model problem, the agent hallucinating a result it never produced. That would have been the easy story to tell and the wrong one. The real cause was step order.

EnrichmentMessenger's disposition logic ran a match-first read: check whether the incoming record matched an existing pattern, assign a disposition based on that match, and only after assigning it, check whether there was any actual basis for the match at all. On the lead that failed, the match-first branch fired, assigned created, and the no-basis check that should have caught the empty enrichment never got a chance to run, because by the time it would have executed, the disposition was already written.

It is a boring bug in the sense that boring bugs are the ones that actually ship. Nothing exotic. Just a conditional that checked things in the wrong order, in the one part of the system where order was the whole point.

The fix

Version 1.1 rewrote the disposition decision as a single ordered tree instead of a set of independent checks, with the no-basis check running first, before anything else gets evaluated. If there is no real basis for the lead (no message, no enrichment, nothing to point to), the disposition resolves to skipped_no_basis and the touchpoint never gets written. Zero credit, because there was nothing to credit.

Re-verification: EnrichmentMessenger 3 for 3. The exact record that failed the first pass now resolves correctly: skipped_no_basis, zero touchpoints. Combined across both agents, 6 for 6, no regression on InboxCopilot. The production substrate's full assertion suite runs 21 for 21.

What I'd do differently

I would have written the no-basis check first the first time, obviously, if I'd seen the failure mode coming. What I'd actually change is earlier than that. I'd design every disposition path as an ordered tree from the start instead of a set of independent checks that happen to run in whatever order the code lists them. Independent checks feel modular while you're writing them. They stop being modular the moment one of the things you're checking is "did anything real happen here," because that question has to come before every other question, every time, or it doesn't mean anything. Attribution systems earn trust in exactly one direction, and a single phantom credit on day one would have spent all of it.

The commits, if you want to look: af7ec15 for the point the repo reached shippable v1 shape, 5d58f51 for the Phase 4 close where the docs finally matched what the code actually did.

What's not in this post

You will find no traction numbers, revenue numbers, or customer counts here, because none exist yet. The Agentic GTM Stack launched without a single case study, on purpose, because the entire pitch is that it does not claim credit it cannot back up, and the fastest way to violate that on day one would have been to publish a made-up "early results" number. The first proof this product gets to point to is its own attribution data, running live on a public dashboard, filling in as real usage happens instead of being backfilled to look good on launch day.

If you want the deeper technical writeup on how the attribution layer itself is structured, that lives at stack.chadtdyar.com/deep-dive. The kit itself is at stack.chadtdyar.com, one-time purchase, self-deploy.

Why I Built a Free Medication Tracker When Medisafe Already Exists

Chad Dyar — Wed, 19 Aug 2026 14:23:13 +0000

Maya needed stitches. Wick had a cough. Benny had a grooming appointment. Same week. When the vet asked me when Maya's last vaccine was, I stood there scrolling through two years of phone photos, trying to date a bandage. Three dogs, three appointments, and nothing written down for any of them.

A few weeks later I was in a different waiting room with my mom's elderly dog, and the same scene played out with higher stakes. A new vet, a dog the family had loved for years, and no health history to hand anyone. The whole medical record lived in my mom's memory, and my mom was stressed enough that her memory was not cooperating.

That waiting room is where CareCadence stopped being a note I kept meaning to write and started being a build. Because the scene repeats everywhere, and the human version is worse. An adult child sits in an ER intake chair and gets asked what medications their father takes, at what doses, since when. The answer exists. It is in a kitchen drawer two towns away, in handwriting nobody can read under fluorescent lights at 2 a.m. The version of CareCadence for people caring for aging parents came from that same moment, and that version is the real product.

The market already had a winner, sort of

Medication apps are not a new idea. Medisafe is the one everyone recommends, and it earned that. But the free tier caps you at two medications, and past that cap you are paying about ten dollars a month. Two medications is a rounding error for the people who need tracking most. The average person managing an aging parent's care is juggling far more than two, across multiple doctors, with schedules that change after every appointment.

I kept turning that over while I built. A caregiver in the middle of the hardest logistics of their life reaches for the standard tool and hits a paywall on the list itself. The list is the whole point. Charging for the list is charging for the exact thing people are panicking about.

What free means here

CareCadence tracks unlimited medications on the free tier. Doses, schedules, adherence, the history a doctor actually wants to see when they ask "how long has he been on this?" There are paid tiers, Plus at $4.99 a month and Family at $9.99, and they exist for households that need more than the core, but the core never gets ransomed. The tracking is the product, so the tracking stays free.

That decision is bad revenue math on a spreadsheet and correct everywhere else. I did not build this app to arbitrage a competitor's pricing mistake. I built it because I have stood in that waiting room twice, and the second time it was not even my dog.

The build itself

The stack is the same one I use across all seven of my apps: Lovable on the front end, Supabase underneath, Capacitor to get it onto phones. Boring on purpose. A solo founder shipping a health-adjacent app does not get to spend novelty points on infrastructure, because every point spent there comes out of the reliability budget, and a med reminder that fires late is not a bug, it is the failure of the entire premise.

The hard part was never the database schema. Medications are just rows. The hard part was designing for two users at once: the person taking the medication and the person worrying about the person taking the medication. Those two people need different things from the same data. One needs a nudge at 8 a.m. that does not feel like a nag. The other needs to answer a doctor's question from two towns away without making a phone call that starts an argument. Most tracking apps pick one of those users and quietly abandon the other. The waiting room taught me you are usually both at different points in your life (sometimes in the same year).

What I would do differently

I would have started from the caregiver. The dogs got me building, and the origin story is true, but the person this product actually serves is the one holding a parent's med list in an intake chair. It took me longer than it should have to see that the "for people" version was not the spinoff. It was the destination.

I would also name that audience earlier in the marketing. "Medication tracker" describes the database. "The med list your family can actually find in an emergency" describes the product. I am still learning to write the second sentence first.

If someone in your life takes more than two prescriptions, the free tier is the whole pitch: carecadence.app. Never miss a dose, start free.

Eight days after launch: zero purchases, and what I am changing

Chad Dyar — Tue, 18 Aug 2026 14:23:04 +0000

I shipped a self-serve product two Mondays ago. Sales page tested clean on two devices. Checkout works. Monitoring is quiet. Eight days later: zero people have finished the free assessment that is supposed to be the front door, and zero purchases.

That is not a soft launch story with a happy ending yet. It might still turn into one. The honest version of this post is the one where I tell you what I actually know eight days in, not the one where I dress a flat line up as a slow build.

What the product is

A twelve week self-serve kit for sales orgs that want to build coaching infrastructure with their own people, no consultant, no calls with me, ever, by design. The whole point is that it works whether I am paying attention to it or not, which shaped the marketing too: it cannot rely on me showing up either.

What I instrumented, and what I did not

PostHog tracks every step of the assessment: started, completed, email submitted, results viewed. That part is solid. The sales page only fires a pageview. There is no buy-click event, so I currently cannot see whether people reach the page and bounce before checkout, or never reach the page at all. That gap should have shipped with the funnel instead of after it, and it is the first fix.

The real number

Zero assessment completions in eight days reads like a conversion problem. It is a traffic problem. A one time batch of launch posts went out the day the page went live, most of it lost to a platform gate I had already decided on before launch and knew would apply, and little went out after that. Traffic that never arrived cannot convert.

What changes this week

The fix is not a better landing page. It is putting this product into the same weekly content rhythm everything else I market runs on, instead of treating launch week as the whole campaign: one assessment link, repeated weekly, across the platforms actually live for me.

If the number still has not moved after a real month of real traffic, that is a more useful piece of information than the one I have now, because it moves the conversation back to strategy instead of tactics. Right now there is not enough traffic yet to know which conversation this is.

Free assessment, if you run coaching for a sales team: chadtdyar.com/coaching-score.

Bring Your Best Self To Work

Chad Dyar — Fri, 07 Aug 2026 14:45:07 +0000

You Built Something. Now Build Yourself.

If you're a developer, you know the feeling. You've shipped features that scale. You've debugged code at 2 AM. You've learned languages, frameworks, databases, and architectural patterns. You've invested thousands of hours becoming better at your craft.

Then why do you feel like you're holding yourself back at work?

The gap isn't technical. It's personal. And it's not something a conference talk or a new tool will close.

Most of us treat personal development like optional content. We'll spend a weekend learning a new stack, but we won't spend an hour understanding how we show up in meetings, how we communicate under pressure, or why we sabotage ourselves right when something matters. We optimize our code but run our lives on default settings.

I wrote "Bring Your Best Self to Work" after watching this pattern repeat across hundreds of people in technical roles. Smart, capable developers who were genuinely stuck. Not because they couldn't solve technical problems. Because they couldn't see the personal problems that were actually in their way.

Here's what I found: the people who moved fastest weren't the ones with the biggest brains or the best certifications. They were the ones who could recognize their own patterns, adjust their approach based on feedback, and show up differently depending on what the moment required. They treated themselves like a system worth optimizing.

That sounds basic until you realize most of us don't do it. We coast on raw talent, blame external circumstances when things don't work out, and then wonder why the same problems keep happening.

The book moves through five core areas: how you think about yourself, how you handle pressure, how you communicate what you know, how you show up in relationships with people who can't code, and how you recover when you stumble.

Each section is built around a real problem I watched developers face. Not hypothetical problems. The actual moments where capability wasn't enough. Where knowing the right answer wasn't the same as saying it in a way people believed. Where confidence became arrogance, or humility became invisibility.

You get frameworks that actually work (not flowery metaphors that sound nice and do nothing). You get permission to be imperfect. You get a realistic path from where you are to where you want to be.

This is for people who want to lead without changing jobs. For people who want to influence projects without formal authority. For people who got hired because they're brilliant at their craft and realized that's not actually enough.

Bring Your Best Self to Work is the book I wish I'd read earlier. Not because I was broken. But because I was capable and underutilized, and I didn't know why until I looked at the personal side of the equation.

If that resonates, the book is here: https://www.chadtdyar.com/books/bring-your-best-self-to-work?utm_source=devto&utm_medium=community&utm_campaign=devto-20260807-bringyourbestse

The Deliberate Breath

Chad Dyar — Fri, 07 Aug 2026 01:01:30 +0000

The Debug You Can't Find in Your Code

You've been staring at the same function for twenty minutes. The logic is sound. The tests pass. But something feels off, and you can't name it. So you keep reading the same lines over and over, hoping the answer will suddenly appear between the curly braces.

It won't.

What you're actually dealing with is not a bug in the code. It's a bug in your nervous system. Your attention has fractured. Your breathing is shallow. Your body is in a low-grade fight-or-flight state, and from that place, your brain cannot generate the kind of relaxed clarity that debugging demands.

This is not poetic. This is physiology.

The Deliberate Breath is not a productivity book wrapped in meditation language. It's a practical guide to understanding how your breath connects to your cognitive load, your attention span, and your ability to solve problems under pressure. For developers specifically, it matters because debugging is not just a technical skill. It's a neurological one. The best debuggers are not necessarily the smartest people in the room. They're the ones who can stay calm enough to see the pattern everyone else is missing.

I wrote this book after watching engineers with junior-level coding skills outpace senior engineers with vastly more technical knowledge. The difference was not intelligence. It was regulation. The juniors had learned (or stumbled into) ways of managing their own nervous systems that kept them functional when the pressure mounted. The seniors had not.

Most technical books teach you what to think. The Deliberate Breath teaches you how to think when the stakes are high and your brain is threatening to shut down on you. That is a different skill entirely.

The book does three things. It explains the mechanics of how breath and nervous system regulation connect to focus and problem-solving. It gives you specific techniques that work in real time, not techniques you have to practice for six months before they become useful. And it addresses the particular pressure points that developers face, whether that's the 2 a.m. deploy that went sideways, the code review where you feel attacked, or the architecture decision you're not confident about.

You do not need to become a meditation expert. You do not need to sit cross-legged for an hour. You need about ninety seconds of deliberate practice to shift your nervous system into a state where your actual skills can show up.

The reason this matters now: we are all working in higher-stress environments than we were five years ago. Remote work, context switching, on-call rotations, the constant flow of Slack, the pressure to ship faster. Your technical skills are the same as they were. Your bandwidth is not. Most engineers I know are not struggling because they forgot how to code. They are struggling because they cannot access the cognitive resources they need because their nervous system is dysregulated.

That is fixable. Not through willpower or discipline, but through understanding how your body works and using that understanding deliberately.

The book is short. It does not waste time on theory that does not connect to your actual work. Every technique in it came from watching engineers use it, fail with it, refine it, and eventually make it their own. Some of those engineers now use it before stepping into a difficult conversation. Some use it when they feel their focus splintering. Some use it when the error message makes no sense and frustration is creeping in.

The goal is not enlightenment. The goal is getting your own best thinking back online when you need it most.

You can find it here: https://www.chadtdyar.com/books/the-deliberate-breath?utm_source=devto&utm_medium=community&utm_campaign=devto-20260807-thedeliberatebr

The Sales Call Version of "Micro Workouts"

Chad Dyar — Tue, 28 Jul 2026 22:11:13 +0000

My trainer told me last week that she's seeing better results from clients doing three ten-minute sessions throughout the day than grinding through one brutal hour at the gym. Something about consistency mattering more than intensity. Cortisol, recovery, sustainability, the usual science.

She wasn't trying to make a business analogy. But I heard one anyway.

I've been tracking my prospect conversations for the past quarter, and the pattern is obvious now. The deals that close aren't coming from the marathon discovery calls where I try to unpack their entire business model in sixty minutes. They're coming from the quick fifteen-minute check-ins where we tackle one specific objection or walk through one part of the pricing model.

The micro workout principle applies to sales execution in ways that feel almost embarrassingly obvious once you see it. Your prospect's attention span works like muscle recovery. You can't force understanding or trust into a single exhausting session. You build both through repeated, focused contact. Three short calls over two weeks will always beat one comprehensive call that leaves everyone drained.

The practical shift is smaller than it sounds. I started blocking my calendar differently. Instead of holding slots for hour-long discovery calls, I book three twenty-minute conversations spread across the week. First call covers their current process. Second call explores one pain point we identified. Third call introduces how we'd solve that specific problem.

The conversion rate difference showed up in under a month. Not because my pitch improved, but because prospects actually remembered our previous conversations. They'd done the thinking between calls. They'd talked to their team. They came back with real questions instead of polite objections.

This maps directly to what I cover in Think On Your Feet, Land On Your Numbers, particularly around call preparation and question sequencing. The temptation in sales is always to pack everything into one interaction. More features, more case studies, more proof points. But that's training for exhaustion, not results.

Micro workouts work because they respect recovery time. Micro calls work because they respect processing time. Both require you to trust the compound effect of showing up consistently instead of trying to earn everything in one session.

Your prospects aren't avoiding your follow-up because they're not interested. They're avoiding it because the last call left them tired.

The newest Presswright title is live on Amazon: Large Print Word Search for Nostalgic Minds: 45 Cherished Themes, Vol...

Chad Dyar — Fri, 24 Jul 2026 22:11:09 +0000

Presswright is a small agent system that takes a puzzle book from theme list to print-ready interior: one agent drafts themed word lists, one validates every grid for solvability and overlap rules, one typesets the large print interior, and a final gate rejects anything that fails a checklist before the PDF ever reaches KDP. The lesson so far: generation was the easy half. The real work lives in the validation gates. When a grid fails, the pipeline logs the defect and regenerates instead of shipping a broken puzzle to a paying reader.

The book that came out the other end is here: https://www.amazon.com/dp/B0H9G4PMW2

Shipping a paperback with an agent pipeline

Chad Dyar — Fri, 24 Jul 2026 21:00:02 +0000

The newest Presswright title is live on Amazon: Large Print Word Search for Nostalgic Minds: 45 Cherished Themes, Volume 4. It is a large print word search book for seniors, and the book is ordinary on purpose. The pipeline is the project. Presswright is a small agent system that takes a puzzle book from theme list to print-ready interior: one agent drafts themed word lists, one validates every grid for solvability and overlap rules, one typesets the large print interior, and a final gate rejects anything that fails a checklist before the PDF ever reaches KDP. The lesson so far: generation was the easy half. The real work lives in the validation gates. When a grid fails, the pipeline logs the defect and regenerates instead of shipping a broken puzzle to a paying reader.