DEV Community: Linhua Zhong

If your AI initiative is pending for 6 months, the bottleneck is probably not technology

Linhua Zhong — Thu, 21 May 2026 14:41:18 +0000

If your AI initiative has been 'pending' for 6 months, the bottleneck is probably not technology. I've seen this pattern repeatedly across companies in both Asia and the US. The tools are accessible, the talent is available, and the use cases are clear. Yet nothing moves. The real constraints are organizational, not technical.

The first structural bottleneck I encounter is unclear data ownership. Who owns the customer database? The sales pipeline? The production logs? Without clear ownership, data remains trapped in departmental silos. Engineering teams can't access what they need, and business leaders won't prioritize cleanup. The tactical fix: assign a data custodian for each critical dataset this week. This isn't a full-time role—just a point person who can answer "Who can approve access to this data?" and "What's the current state of this dataset?" Make it someone who uses the data daily, not a C-level executive.

The second bottleneck is the absence of an operations sponsor. Many AI initiatives die in the "pilot purgatory" because no one is accountable for production deployment. The data science team builds something, the business leaders express interest, but no one owns the operational handoff. The tactical fix: identify an operations sponsor who will attend weekly implementation meetings. This person should have budget authority and decision-making power, not just advisory influence. Their first task is to define what "done" looks like—specific milestones with clear completion criteria.

The third bottleneck is the lack of success metrics. Without measurable outcomes, AI initiatives become abstract exercises. Teams build models without knowing what constitutes success, leading to endless revisions and scope creep. The tactical fix: define a single, measurable success metric this week. Not "improve customer experience" but "reduce average handle time by 15% for Tier 1 support tickets." Not "optimize inventory" but "reduce stockouts for top 10 SKUs by 20%." The metric should be business-focused, not technical.

Technology is rarely the constraint. I've worked with companies using open-source tools to solve problems that others couldn't address with enterprise solutions. The difference wasn't the tools—it was the organizational clarity. When data ownership is clear, when someone owns operations, and when success is measured, AI initiatives move forward regardless of the technology stack.

The tactical fixes I've outlined—assigning data custodians, identifying operations sponsors, defining success metrics—can be implemented by any non-technical leader this week. They don't require technical expertise or budget approval. They require clarity and accountability.

What's the single organizational constraint holding back your AI initiative right now?

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

The job of an AI engineer inside a 40-person company is not what most CEOs think it is

Linhua Zhong — Thu, 21 May 2026 14:36:06 +0000

CEOs of 40-person companies often imagine their first AI hire will be a model trainer—someone who builds custom neural networks from scratch. Reality check: that's maybe 10% of the job. The real work is less glamorous but more critical. Most days are spent cleaning data, managing third-party APIs, and translating between technical teams and business stakeholders. The actual model training happens mostly in vendor platforms like OpenAI or Anthropic. The real value is in connecting those tools to your actual operations.

Let's walk through three typical weeks in the life of an AI engineer at a small company.

Week one: Data plumbing. The team needs to connect customer support tickets to knowledge base articles. The engineer spends four days writing scripts to extract text from Zendesk, clean it of HTML tags, and structure it for retrieval. The fifth day goes to testing edge cases—what happens when a ticket has no subject line? Or when the article contains a table? No model training happens. Just making sure the input pipeline works.

Week two: Vendor management. The company wants to use OpenAI's API for summarization. The engineer evaluates three pricing tiers, tests rate limits, sets up monitoring for API failures, and writes fallback logic when the service is slow. They spend two days documenting the quirks—how the API handles technical jargon, its tendency to hallucinate dates. Then they build a wrapper that handles all this complexity so the business team doesn't need to think about it.

Week three: Translation. Sales wants a tool to draft follow-up emails. The engineer sits with the sales team for three days to understand their actual workflow—what information they need to include, what tone to use, how they handle objections. They build a prompt library that maps to different scenarios, then create a simple interface where sales reps can input key details and get drafts. The heavy lifting isn't in the model—it's in making sure the output matches how salespeople actually work.

So when you're hiring for this role, don't look for deep learning expertise. Look for someone who can build data pipelines, understand API limitations, and translate business needs into technical requirements. The best candidates have experience with ETL tools, cloud services, and have worked with non-technical teams. They should be able to explain trade-offs clearly—why a certain approach might be slower but more reliable, or how to handle missing data. The magic isn't in the models themselves—it's in making them work in your messy, real-world environment.

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

18 months helping 12 small businesses set up internal AI teams: three lessons I did not expect

Linhua Zhong — Thu, 21 May 2026 14:30:55 +0000

Last Tuesday, I watched a founder pace across her screen. She'd just told me her team had automated 30% of their weekly reporting using internal AI tools. "I feel guilty," she said. "Like I'm cheating somehow." This conversation—this feeling of unease about doing AI "the right way"—has played out in different ways across all 12 companies I've worked with over the past 18 months.

What started as a straightforward project—help small businesses build internal AI capabilities—became something more nuanced. The companies ranged from a 35-person logistics firm in the Pearl River Delta to a 50-person marketing agency in Chicago. Their challenges were unique, but patterns emerged that surprised me.

Lesson one: The biggest bottleneck isn't technical knowledge—it's psychological. Many founders assume they need to hire AI experts or train everyone in machine learning. What they actually need is permission to experiment. At the logistics firm, we started with a simple exercise: "What's one task you do weekly that feels repetitive?" The answer became their first AI project. The technical implementation took three days. The permission to think differently took three weeks.

Lesson two: Your existing processes are more valuable than you think. We often rush to automate without documenting what we're automating. A 40-person e-commerce company in Singapore tried to implement AI customer support before documenting their current support workflow. The AI outputs were inconsistent because the underlying process wasn't clear. Once they mapped their existing conversations—how they escalated, what information they collected—the AI suddenly made sense. The tech was ready. The process wasn't.

Lesson three: The most valuable AI applications are boring. Every founder wants to talk about AI strategy or competitive advantage. The real wins come from small, practical improvements. A 35-person design firm in Portland used AI to standardize their client onboarding process. Nothing revolutionary. Just consistency. They reduced the time spent on administrative tasks by about 20% each week. That's not a (amount withheld). That's a sustainable improvement that compounds.

The pattern across all these companies is the same: AI adoption succeeds when it serves human work, not replaces it. The best implementations make people's expertise more valuable, not less. They handle the routine so humans can focus on what they do best: judgment, creativity, and nuanced decision-making.

If you're thinking about AI for your team, don't start with technology. Start with questions: What work makes your team feel stretched thin? What tasks happen repeatedly? Where does valuable knowledge get lost when people leave? The answers will point you toward meaningful applications.

The most practical takeaway? Schedule a 90-minute "process mapping" session with your team this week. Not about AI. About your current work. Document the steps, decisions, and handoffs in one critical workflow. You'll likely discover opportunities where AI can support—not replace—what you already do well. 📊

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

At what headcount does an internal data flywheel begin to compound meaningfully?

Linhua Zhong — Thu, 21 May 2026 14:25:40 +0000

Having observed dozens of internal data initiatives across SMBs, I've noticed consistent thresholds in data flywheel effects that seem independent of domain. Below 50 employees, data collection feels chaotic—more noise than signal. Between 50-500, patterns emerge but remain unstable as processes and roles shift. At 500+, particularly around 750-1000 employees, the compounding becomes visible: customer support data improves product insights, which reduces support tickets, creating a self-reinforcing cycle. Legal document analysis similarly compounds around this scale, as enough case history exists to identify precedents without overwhelming manual review.

These thresholds assume no specialized data teams—just embedded practices across functions. The 5000 employee mark seems to be where flyheels become institutionalized, requiring deliberate governance to prevent stagnation. Domain matters: e-commerce support might compound at 300 if transaction volume is high, while manufacturing quality data may need 800+ to overcome process variability.

Counterexamples welcome: Have you seen meaningful compounding at different scales? What non-obvious factors accelerated or delayed your flywheel? The question isn't about "big data" but the organizational inflection point where data begins to work for itself.

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

First AI hires at small companies: the single hire trap

Linhua Zhong — Thu, 21 May 2026 14:17:52 +0000

We're seeing a pattern with companies under 50 people: they default to hiring one ML engineer as their first AI hire, and it consistently underperforms. The engineer gets stuck in research mode without the operational context to ship, or builds models that don't connect to business needs. Our working hypothesis is that you need a triangle: an engineer who can build, an operations contact who understands the workflow, and a data owner who can ground the work in actual business problems. Without all three, the first AI hire often becomes an expensive consultant rather than a team member.

We're curious how others are solving this. Are you finding that the single hire model works in specific contexts? What's the smallest team that's actually delivering value with AI rather than just experimenting? Have you seen successful models where the AI hire reports to a non-technical function? We're particularly interested in counterexamples where the single hire has thrived without the triangle structure—what conditions made that possible?

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

A 30-day playbook for building internal AI teams in SMBs

Linhua Zhong — Thu, 21 May 2026 14:15:05 +0000

We've open-sourced a 30-day playbook for SMBs (10-100 people) looking to build their own internal AI capability. It's a free document with reference Python notebooks, available at [github link].

After 12 engagements with SMBs in Asia and the US, we kept seeing the same three failure modes: teams treating AI as a magic box, starting with tools instead of problems, and attempting to boil the ocean. This playbook is our attempt to address those patterns.

The document structures a month-long rollout across four weeks: problem scoping and data inventory (week 1), model selection and prototyping (week 2), integration and workflow design (week 3), and team scaling and governance (week 4). It includes four reference notebooks covering data preparation, prompt engineering, model evaluation, and deployment patterns. Three case study writeups show how teams applied this framework to real problems in customer support and operations.

What's not included: no SaaS platforms, no tool recommendations, no promises of "AI transformation." We're not selling anything—just sharing what's worked in the field.

The playbook comes from 12 engagements across different industries. The sample size is small, and we're sharing it to get feedback from others doing this work. We expect it will need refinement as more teams experiment with this approach.

We're particularly interested in hearing about patterns we've missed, assumptions that don't hold in other contexts, and alternative approaches that have worked for others. The GitHub repo includes an issues section for structured feedback.

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

Small AI wins: what's your <100hr deployment?

Linhua Zhong — Thu, 21 May 2026 14:11:20 +0000

Just wrapped up a small FAQ bot for a support team. Took about 60 hours total from discovery to deployment. The client had 4 support reps spending 3 hours daily answering the same basic questions. Now the bot handles ~40% of those inquiries, saving roughly 3 hours per day across the team. Not revolutionary, but it's a tangible improvement that didn't require a six-month project or a dozen consultants.

What's the smallest useful AI deployment you've shipped? I'm looking for concrete examples that took under 100 hours to build and delivered real value.

We're seeing a few patterns emerge from these quick wins:

FAQ auto-reply: The one we just finished. Most companies have a set of questions that make up 60-70% of their support volume. A simple bot that can answer these with company-specific knowledge (not generic internet responses) frees up humans for more complex issues.
Contract summarization: Legal teams drowning in NDAs and vendor agreements. A tool that can extract key terms, obligations, and dates from contracts saves hours of manual review. One client built this in ~45 hours and cut their contract review time by about 50%.
SOP chatbot: Operations teams with documented processes that nobody reads. A chatbot that can answer "how do I..." questions using existing SOP documents. One implementation took ~70 hours and reduced the time to find procedures by ~75%.

Which of these have you tried? What other small-scale deployments have worked for you?

The key with these small projects is focusing on a single, well-defined problem where you can clearly measure the before and after. No need to boil the ocean—just solve one specific pain point that your team is facing today.

What's your smallest-but-most-useful AI deployment? Let's swap notes.

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

Should we even use AI? Our 40-person company is trying to figure this out.

Linhua Zhong — Thu, 21 May 2026 14:09:11 +0000

Hey everyone,

I'm the owner of a small service business with about 40 people, and I'm trying to get a handle on how we're approaching AI. Not as a magic solution, but as another tool in the toolbox. The question keeps coming up: should we even be using AI, and if so, how?

From talking with other small business owners in similar positions, I'm hearing a few patterns. Some are diving in headfirst, trying every new AI tool that comes across their desk. Others are completely avoiding it, worried about costs, time investment, or just another tech trend that'll pass. A few are taking a more measured approach, identifying specific tasks where AI might actually save time or improve quality.

What I'm not hearing much about is a clear framework for making this decision. It feels like we're all just guessing based on our own comfort levels with technology rather than a business case.

So I'm genuinely curious how others are handling this. Specifically:

What's your actual decision-making process for adopting new AI tools? Is it based on specific problems you're trying to solve, or just exploring what's out there?
How do you separate the genuinely useful AI applications from the hype? What signals do you look for?
Who in your organization is driving this conversation - leadership, specific departments, or is it more grassroots?
Have you found any practical use cases that actually delivered measurable value for a small team, beyond just "it's cool"?

We're still figuring this out ourselves, and I'd be happy to share what we learn from this discussion in a follow-up post if there's interest.

Thanks for sharing your experiences.

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

We paid consultants a five-figure sum for AI advice that gave us nothing. Here's what actually worked.

Linhua Zhong — Thu, 21 May 2026 14:03:39 +0000

I'm going to admit something that might get me flamed: we tried hiring AI consultants twice, and both times it cost us more than it returned. I'm not proud of this, but I think it's worth sharing because I see so many founders making the same mistake.

First, let me be clear about what we tried. The first consultant came highly recommended - former Big Four, fancy LinkedIn profile, spoke at conferences. We paid him a five-figure sum for a "comprehensive AI transformation roadmap." What we got was 80 slides of buzzwords and a list of tools we already knew about. The second was a boutique shop that promised "practical AI implementation" for a five-figure sum. Their deliverable was a 50-page PDF that could have been written by ChatGPT.

Why did it fail? Simple: these consultants didn't know our business. They treated AI like some abstract concept rather than a tool to solve specific problems. They didn't understand our workflows, our customers, or our pain points. The first one spent more time telling us about the history of machine learning than understanding how we actually operate. The second one kept referring to "synergies" and "paradigm shifts" without ever explaining what that meant for our day-to-day operations.

What finally worked was building a small internal team - what we call our "AI triangle." We didn't hire data scientists from FAANG. We took three existing employees and gave them specific roles:

A process expert - someone who knew our workflows inside and out
A tech-savvy operator - someone who could actually implement the tools
A translator - someone who could bridge the gap between technical concepts and business needs

We gave them 10 hours a week dedicated to AI experimentation. No grand transformation projects. Just small, practical experiments. We started with something simple: automating our quote-to-contract process. The process expert identified the bottlenecks, the tech operator found a no-code solution, and the translator made sure everyone understood what was changing.

The results weren't revolutionary, but they were real. We cut quote-to-contract time roughly in half. We reduced the time spent on customer support ticket routing by about 40%. We improved our sales forecasting accuracy by a noticeable but not dramatic margin. These weren't game-changers, but they were improvements we could see and measure.

The key insight? AI isn't something you buy - it's something you learn to do. The consultants treated it as a product they could sell us. The triangle treated it as a skill they could develop. The difference is everything.

We're not AI experts now, but we're not beginners anymore. We have a process for identifying opportunities, testing solutions, and measuring results. And it cost us nothing beyond some salary adjustments and a few hours a week.

So here's my question to you all: have you found a sustainable way to build AI capabilities without breaking the bank or getting lost in hype? I'm tired of seeing founders throw money at consultants who don't understand their business. What's working in the real world?

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

Data flywheel for small businesses (no ML PhD required)

Linhua Zhong — Thu, 21 May 2026 14:03:22 +0000

LLMs decay without your data. Generic models lose relevance fast. Your business has unique patterns, customer language, and operational knowledge that generic AI can't replicate. That's your competitive advantage.

Customer conversations. Support chats, emails, call notes. This is pure gold for understanding your customer's exact language, pain points, and how they describe your solutions.

Internal documents. Meeting notes, project docs, decision records. These capture your tribal knowledge, how things actually get done, and the nuances of your business that live in people's heads.

Operational data. Simple spreadsheets tracking your workflows, sales processes, or customer journeys. Not the fancy analytics, just the raw stuff that shows where things slow down or succeed.

Public-facing content. Website copy, product descriptions, social posts. This shows how you communicate your value in your own voice, which trains AI to represent you authentically.

The 50/500/5000 rule: 50 conversations reveal patterns. 500 documents build context. 5000 data points create a self-reinforcing system where insights feed better data, which creates better insights.

Reply YES if you want the checklist to map your existing data assets into a practical, no-ML-required AI foundation. No hype. Just what works.

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

The 3-person minimum team to actually ship AI inside a 50-person company

Linhua Zhong — Thu, 21 May 2026 13:57:00 +0000

Most companies hire 1 ML engineer and wonder why nothing ships. They're missing the operational layer that turns models into value. I've seen this pattern play out across 30+ SMBs.

The 3-person minimum team to ship AI in a 50-person company:

ML Engineer: Owns model development. Week 1: Build a simple classifier on your existing data to categorize support tickets.
Product Manager: Owns problem framing. Week 1: Interview 5 customers to identify 1 high-frequency problem AI could address.
DevOps Engineer: Owns deployment. Week 1: Containerize a simple model and set up basic monitoring for accuracy drift.

The ML Engineer isn't just a coder. They need to translate business problems into technical specs. I've seen too many teams build models nobody uses because this connection was missing.

The Product Manager must understand both the domain and AI's limitations. Week 2: Define success metrics for your ticket classifier—not just accuracy, but how it reduces response time.

The DevOps Engineer ensures models actually run in production. Week 3: Set up alerts for when your model's performance drops below 90% on your ticket classification task.

Common mistake: Hiring an AI consultant without assigning an internal ops owner. The consultant leaves, and the model dies. I've seen this happen 17 times. Always build internal capability alongside external help.

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

Why most SMBs fail at AI adoption (and what works instead)

Linhua Zhong — Thu, 21 May 2026 13:56:30 +0000

Most SMB AI projects fail because they treat AI like a magic tool, not a capability. They buy software, expect instant ROI, then wonder why nothing changes.

Reason 1: No clear problem definition. Teams build AI solutions without answering "What specific human work are we trying to improve?" No problem statement = no real solution.

Reason 2: Expecting tech to fix process issues. If your workflow is broken, AI won't fix it. Automate chaos, you get faster chaos. Fix the process first.

Reason 3: No dedicated team. AI isn't a side project. It needs someone who owns it, understands the domain, and can bridge tech and business needs. No ownership = no progress.

AI adoption works when you treat it like building a team: clear problems, solid processes, dedicated people. Reply if you want details on how we help companies do this right.

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.