April 2026 · Updated August 2026

This Is How I Would Implement AI at a 40-Person Startup

I led the AI rollout at Elephant Energy, a 40-person climate tech startup with heat pumps, real trucks, and real customers. Not a software company. Most companies get this wrong — they buy tools, write policies nobody reads, and wonder why nothing sticks. This is the playbook I'd run if I walked into another 40-person company tomorrow, in the order I'd run it in.

Elephant was a home electrification company. Field technicians, sales advisors, designers, ops people, and a small engineering team. Forty people across three states installing heat pumps, induction stoves, and EV chargers. Not a software company. A real company, with real trucks and real customers.

When I set out to make us an "AI-empowered" organization, I quickly learned that the hard part had nothing to do with technology. There are a thousand AI tools to choose from, and that abundance is paralyzing. Half the team was excited and racing ahead with random free tools. The other half was scared, quiet, and convinced this was the beginning of the end of their jobs.

The technology was easy. The change management was brutally hard.

This is how I'd run it now — whether as CTO, head of AI, or a founder starting fresh — at a 40-person company that isn't a software shop. It starts with something I didn't fully appreciate going in, and would now put ahead of everything else.

0. Get real buy-in from the top. This is a call to take risk.

Before you pick tools, write a policy, or run a single pilot: secure genuine buy-in from leadership (co-founders or CEO on down) and support from your investors. And be honest with yourselves about what you're actually signing up for — this is a call to take risk.

If you want AI to actually change how the company operates, you are going to change systems, tools, processes, people, and workflows. You're going to change the way the leadership team thinks. Sales motions will look different. Ops teams will shrink or reshape. Roles will blur. Decision rights will shift. Some of the org chart will not survive contact with the new reality. That is not a side effect of doing this well — it is doing it well.

The question you're really committing to is this: "If we were starting from scratch, with agents as first-class participants, how would we design this?" You run that question across sales, ops, finance, support, engineering. The answers are rarely what you already have. Marginal gains come from bolting AI onto current processes; compounding returns come from redesigning the process itself.

You cannot drive that from the middle. You need the CEO publicly committed, the co-founders aligned, and the investors supportive of the disruption that comes with real change. If your investors treat AI as a line item for the next board deck, they'll run out of patience the first time a team's productivity temporarily dips during a migration. And it will dip. That's the cost of rebuilding the plane while flying it.

The hard part: If a critical person on the leadership team is not genuinely bought in — not "supportive in meetings" but actually bought in — you need to seriously consider whether they belong in the seat. That sounds extreme. It is. It's also necessary.

AI change management dies fastest when one key leader quietly resists, shields their team, or treats it as someone else's initiative. A single skeptical VP will stall the whole org. You'll spend more energy managing around them than moving the work forward, and the rest of your leadership team will notice.

The same rule applies one level down. Hire AI-first builders — people who already ship with AI and can show you the work. Proof over opinions, demos over resumes. Promote internal champions who reimagine workflows instead of defending the old ones. Don't let anyone talk their way into an AI role; look at what they've actually built.

If you don't have that alignment on day one, don't pretend you do. Spend your first weeks getting it — explicit, on the record, with the hard conversations out of the way. Then begin.

1. Decide up front: productivity, or transformation.

The first choice, and the one most companies never explicitly make, is what you're actually aiming for. Both answers are legitimate. Conflating them is where it falls apart.

Productivity is bolt-on. Faster emails, cleaner meeting notes, better first drafts, quicker code reviews, smarter search. Ships fast. Low drama. Realistic upside is somewhere in the 10–20% range across knowledge work. You are the same company, doing the same work, just faster. That's a fine outcome. Some companies should stop there.

Transformation is a different animal. The shape of the work changes. Some jobs shrink, some jobs merge, some new jobs get invented. Your sales motion looks different. Your ops team looks different. Tools you were paying for get replaced. You commit to a period of instability — six to eighteen months of things being worse before they're better — in exchange for a company that operates on a different curve when it's done.

Pick one. Say it out loud. Tell the company which one you're running. The thing you cannot do is nod along to "transformation" in a board meeting and then quietly run a productivity playbook. Everyone will know, and the credibility cost is enormous.

A useful test: If your leadership team can name three roles or workflows they expect to look meaningfully different in a year, you're doing transformation. If they can't, you're doing productivity. Neither is wrong. Only one of them is what most people mean when they say "AI strategy."

2. Pick one LLM. Standardize ruthlessly.

This is the decision most companies refuse to make, and it costs them everything.

When everyone uses different tools, you get chaos. One person uses ChatGPT, another uses Claude, a third uses Gemini, a fourth uses Grok, and a fifth ends up on some random free tool that trains on your data. Nobody builds shared prompts. Nobody shares what works. Institutional knowledge about how to use AI stays trapped in individual heads, which is the exact problem AI was supposed to solve.

It mostly doesn't matter which one you pick. ChatGPT, Claude, Gemini, Grok — they are all extremely capable, and the ceiling of each one moves every quarter. What matters is that you pick one, standardize on it, buy enterprise seats for the whole company, and lock the login and data policies behind your SSO. One platform, one set of credentials, one place to build. Whichever one you pick will be "wrong" within a year, and you should switch when it is. You can't switch what you never chose.

The principle: Standardize on one ecosystem, not one tool. Your primary LLM is the foundation. Embedded AI in your existing SaaS tools (CRM, email, project management) is the accelerant. Everything else requires approval.

Alongside your primary LLM, there is a companion category of prototyping tools that has become genuinely important: Replit, Cursor, Claude Code, Claude Artifacts, and OpenAI Codex. These let anyone in the company build a working thing in an afternoon — a small internal tool, a scraper, a dashboard, a script that automates a painful piece of workflow. Sanction at least one of them so curious people know what's fair game and the security team isn't blindsided by shadow tools.

This doesn't mean you can't experiment. Have a process for it: post in a shared channel, get a yes or an alternative within 24 hours. Default to yes, with guardrails. But the default stack is non-negotiable.

My biggest mistake: Not just getting started. I spent too long deliberating over which LLM, which agent framework, which vendor, which policy. The right move was to pick something reasonable, get everyone on it, and iterate. You can trade one platform for another later. You cannot recover the year you spent not starting. Just go. Go, go, go.

3. AI-empowered, AI-first, and AI-native are not the same thing.

The framing matters more than you think, and the words that get thrown around — AI-native, AI-first, AI-empowered — get used interchangeably in a way that hides the fact that they describe fundamentally different companies.

When you tell a team of 40 people that you're "implementing AI," half of them hear "you're replacing me." That's a trust problem no amount of tooling can fix. When you build for empowerment, you design tools that keep humans in the loop. When you build for automation, you design tools that remove them. Those are fundamentally different systems, and the first one is the only one that works when your business runs on trust, judgment, and customer relationships.

Pick the frame that actually matches your ambition. If you said "transformation" out loud in section 1, you probably owe your company an AI-first plan, not just an AI-empowered one. Be honest about which one you're building, and use the word that matches.

4. The guardrails are the product.

Most AI policies read like legal documents written by people who've never used AI. I'd try to fit mine onto one page, and the core of it would be this:

If you wouldn't email it to a stranger, don't paste it into an AI tool.

That one line does more for your security posture than a 20-page policy would. People understand it immediately. It's memorable, actionable, and doesn't require a training session to internalize.

Beyond that, keep it simple:

The "ask first" category is the key insight. Most companies default to "no" on anything ambiguous. Default to "yes, with a conversation." That one shift turns AI adoption from a compliance exercise into a culture of experimentation.

Make the secure path the easy path. Company-managed accounts on your standardized LLM, embedded AI on the tools people already use, prototyping tools approved through official channels. When people have a fast, sanctioned way to use AI, they don't reach for the sketchy free version.

The other honest thing to admit: this is extremely hard to police. It's the same problem as trying to police what people say in internal meetings, in Slack, in email, or in text messages — you can't, not really. You can log tool usage. You can audit your corporate accounts. You cannot see the free chatbot open in someone's personal browser tab. The only real defense is to hire people you trust, tell them clearly what actually matters, and expect them to use their best judgment. A short, memorable rule that people believe in beats a 20-page policy nobody reads.

5. Start with the AI that's already in your tools.

Every company I talk to wants to build custom AI agents. Almost none of them have turned on the AI features already embedded in the software they're paying for.

Your CRM has AI. Your email has AI. Your project management tool has AI. Your call recording software has AI. Your workflow automation tool has AI. Most of these features are included in your existing subscription.

You'll get more leverage from turning on embedded AI features across your existing stack than from any custom tool you build in year one. The reason is simple: embedded AI operates inside the workflow. There's no context switching. There's no "open a new tab and paste this in." It just works where people already work.

The sequence that works: First, activate embedded AI in existing tools. Second, train people on the standard LLM. Third, build custom agents for specific, well-defined problems. Most companies start at step three and skip one and two entirely.

6. Solve for context before capability.

The models are already good enough. The real bottleneck is almost never the LLM — it's that the knowledge your agent needs lives in people's heads, in meeting audio nobody transcribed, in chat threads nobody searches, and in systems that don't talk to each other.

An agent is only as good as the context you can put in front of it. If your operating knowledge is locked in tribal memory and hallway conversations, no model will save you. The unglamorous work is the work:

A useful frame: if it isn't captured, an agent can't use it. If it has full context, almost anything can be automated. Context engineering is a core competency, not an afterthought, and the quality of what you feed an agent determines the quality of what it produces.

Most companies skip this step because it's boring. They want to plug in a fancy agent and watch it sing. What they get instead is a confident hallucination machine, because the agent doesn't know who the customer is, what you promised them last month, or what the technician already tried on site.

7. Crawl, walk, run, sprint.

We built a design assistant that helped our sales advisors make HVAC system recommendations. The roadmap for that one tool looked like this:

  1. Crawl: Knowledge retrieval. Feed it internal playbooks and design guidelines. It answers questions with links to existing documentation.
  2. Walk: Structured Q&A. Train it on real question-and-answer pairs from internal channels. It starts giving recommendations in a consistent format with confidence scores.
  3. Run: Connected systems. It reads from your proposal tool and CRM, pulling real customer data into its recommendations.
  4. Sprint: Autonomous actions. It updates records, triggers workflows, and handles routine design decisions without human intervention.

Most companies try to jump straight to sprint. They want the autonomous agent that does everything. The result is a brittle system that nobody trusts, built on data that hasn't been validated, making decisions that haven't been tested.

This is also where agents, custom tools, gems, and skills come in — the higher rungs of the ladder, not the entry point. A custom agent built on top of a team that hasn't mastered prompting is a very expensive way to look busy. Get your people fluent with the basics first — the standard LLM, embedded AI in existing tools, a shared prompt library, a few prototyping wins. When the basics are in place, agents and skills are genuinely transformative. Before that, they're a demo.

The crawl phase isn't glamorous, but it's where you learn what data you actually have, what's missing, and what format it needs to be in. Skip it and you'll pay for it later.

8. Treat agents like employees.

Once you have more than a couple of agents in production, start treating them the way you treat people.

Give them names. Give them scoped roles. Write a short onboarding doc for each one that explains what it knows, what it can touch, and what it's explicitly not allowed to do. Drop them into the same Slack or Teams channels as the humans they work with, so interactions are visible and reviewable.

This isn't whimsy. It solves three real problems:

Permissions should be designed for the agent, not inherited from the person who spawned it. Sometimes an agent legitimately needs broader access than any one human — it has to see across teams to be useful. Sometimes it needs far less. Both require explicit decisions, not accidents of IAM configuration. When agents are doing 100x or 1,000x the volume of any individual, "we'll clean up access later" isn't a plan; it's a breach.

9. Be willing to change roles, titles, and workflows. Or don't bother.

This is the section where most transformation programs quietly die. Companies say they want AI transformation, and then refuse to change anyone's role, title, workflow, or reporting line. You can't have it both ways.

If you decided in section 1 that you're doing transformation, you have to be willing to restructure. Some roles will merge. Some will shrink. Some new ones — an AI product owner, a workflow engineer, someone who owns the internal tool platform, someone who runs the agent fleet — will need to be invented. Titles will change. Workflows will get rebuilt. Systems and tools you were paying for will get retired. Processes that were sacred cows will get slaughtered.

You cannot bolt AI on top of an org chart designed for a pre-AI company and expect it to work. It's the equivalent of stapling a jet engine to a horse-drawn carriage and being disappointed when the horse still sets the pace. You're screwed if you try.

The mistake: Buying tools, running trainings, celebrating pilots, and then leaving every role, title, and workflow exactly as it was. That's how you end up with a company that spent a fortune on AI and moved 5% faster. Protecting the shape of the org from any real change is the same as choosing productivity — just with a bigger bill.

This part is unpopular because it's the part that touches people. Some team members will thrive in the new shape. Some will not. Your job is to be honest about that early, invest in the people who want to grow into the new roles, and make clean, humane exits for the ones who don't. Pretending the org can stay static while the work is being rebuilt is the fastest way to burn trust with everyone.

10. Do it together. Celebrate builds, failures, and weirdness. In public.

Run regular sessions where anyone in the company can demo something they've built or discovered with AI. A sales advisor who automated her follow-up emails. An ops manager who built a scheduling optimizer. A field tech who used AI to troubleshoot a tricky installation.

The key word is "anyone." Not just the engineering team. Not just the people who were "good at tech." Anyone.

Celebrate the failures too. The bot that hallucinated a product model that doesn't exist. The automation that sent the wrong email. The prompt that returned something hilariously wrong. Failures mean someone was trying. Not trying is the only real failure.

This has to be done together, top to bottom, as a company, or it doesn't stick. It cannot be a founder-and-a-couple-champions thing. It cannot be an engineering-department thing. It has to be everyone — the CEO demoing something clunky, the field tech demoing something brilliant, the ops lead sharing a prompt that saved her a full afternoon. If any layer of the company opts out, the rest will notice and quietly follow.

It also has to be fun, or it won't compound. AI adoption driven by mandates and compliance training dies on contact with reality. AI adoption driven by curiosity, play, and showing off to your teammates snowballs. Nobody needed to be told to use AI at Elephant. They wanted to, because their coworker just demoed something awesome and they wanted to build something better.

The culture shift: Never punish someone for experimenting within the guardrails. Never punish an AI output that went wrong if the person caught it and reported it. The only things worth punishing are not trying, and hiding mistakes.

How to know it's working

Business metrics (revenue per employee, cycle time, cost per unit of output) lag by many months. Lean on leading indicators:

Be honest about what tokens are and aren't. They are not the outcome. The outcome is smarter decisions and better-informed people. Tokens are a signal that people are engaging with the tools — a good start, not a finish line. Watch the movement more than the absolute numbers. A team whose usage doubles quarter over quarter is on a very different trajectory from one whose usage is flat, even if the flat one started higher.

11. Learn together, or don't bother.

Individual AI adoption is a dead end. One person gets really good at prompting and builds amazing tools that nobody else understands, can maintain, or even knows exist. When that person leaves, all the knowledge walks out the door.

Make AI literacy a team sport. Shared prompt libraries. Internal channels where people post what worked and what didn't. Office hours where anyone can bring a problem and you build a solution together in real time.

Your best AI users won't be the most technical. They'll be the most curious, and the most willing to share what they learn. Create the conditions for that and get out of the way.

The bottom line

Implementing AI at a 40-person company isn't a technology problem. It's a change management problem, and it's a leadership problem. The scared people need safety. The excited people need guardrails. Everyone needs to feel like they're learning together, not being left behind. The technology is the easy part.

If I were walking into a different 40-person company today to lead this work, the order would be clear:

  1. Get real, on-the-record buy-in from the top. This is a call to take risk.
  2. Decide out loud whether you're doing productivity or transformation.
  3. Standardize on one LLM and one prototyping tool. Just start.
  4. Frame it honestly — AI-empowered, AI-first, or AI-native. Pick the word that matches your ambition.
  5. Write guardrails your people can actually remember. Accept that you can't fully police it.
  6. Start with the AI you're already paying for.
  7. Fix your context problem before you chase capability.
  8. Build incrementally. Crawl before you sprint. Agents, tools, gems, and skills come last, not first.
  9. Name your agents. Give them scoped roles and clean permissions.
  10. Be willing to restructure — roles, titles, workflows, systems, tools, processes. Or admit you're doing bolt-on.
  11. Do it together. Celebrate in public. Measure adoption, happiness, and token usage as leading indicators.
  12. Learn together. Have fun.

And start now. The compounding advantage goes to the people who begin today and stay with it. You don't need the perfect architecture or the next model release — you need to start iterating while everyone else is still writing strategy decks. Cloud took 15 years to grow 1,000x after the tech world agreed it was inevitable. Agents are on a similar curve. The companies that wait for the dust to settle will be the dust.

Everything else is noise.

Free Tools I Built

Electrify Everything Now. Free calculators for solar, rate plans, and appliance replacement timing. All AI-first, all open.

Related Reading

You Probably Don't Need a Panel Upgrade. The most expensive lie in home electrification, and 12 companies proving it wrong.

The Electrification Sequencing Problem. What should you electrify first? A decision framework for homeowners.

Josh Lake is a serial entrepreneur thinking about AI and the convergence of energy and intelligence. He's the founder of Electrify Everything Now, and previously co-founded Elephant Energy.

Find him on LinkedIn and X, or go back to joshlake.ai.