Tiny Big Spark
Search
HOME
ARCHIVE
TAGS
RESOURCES
RESOURCES
Title
SIGN IN
SUBSCRIBE
Tiny Big Spark
Sep 30, 2026
Your 13-Week AI Plan for Engineering Teams
Your 13-Week AI Plan for Engineering Teams
00:00
06:13
1×
Transcript
0:00
If your VP asked for your AI plan tomorrow, what would you hand them? Not a slide about the future, not a list of tools, an actual plan. Let's build one.
0:10
Hi, I'm Erwin Dwight, and this is Tiny Big Spark, the engineering leadership podcast. Today, a thirteen-week plan for bringing AI into your engineering team.
0:18
Four stages, four small artifacts, and one five-minute action you can do today. Here's the idea: treat AI adoption like a release, not a hobby.
0:28
Most of us learn AI the same way, alone in spare minutes, one prompt at a time. That's a good start, but it doesn't tell your team where AI is safe to use.
0:40
It doesn't say who owns the result, and it doesn't show whether any of it is helping. Sooner or later, your leadership will ask three questions: Where do we use it and where do we not? Who is accountable when it's wrong?
0:52
And how do we know it's worth the cost? If you're growing from manager toward director, those questions matter even more. Leading a system means having a considered answer, not just enthusiasm. So here's the setup.
1:05
One team, one workflow, say code review or incident writeups, three hours a week for thirteen weeks. Use two tools side by side so you learn what's tool specific. Keep a simple log, date, task, what worked, what broke.
1:19
And set one firm rule, no confidential code, no customer data, no credentials and tools your company hasn't approved. Here's a weekly rhythm that works.
1:27
One hour to try something, one hour to write down what happened, one hour to talk it through with a peer or a mentor.
1:33
Sharing your log with one trusted person keeps you honest, and it's the fastest way to learn from someone a few steps ahead of you. Stage one, sandbox. Weeks one to three.
1:44
The goal, learn where AI is strong and where it fails using your own real work. Use it daily. Summarize long threads. Draft review comments. Explain unfamiliar code. Then try to break it.
1:57
Ask questions you already know the answer to. Give it vague input on purpose and log every miss with a cause, missing context, invented detail, a wrong assumption. Your artifact is a failure log. Four lines.
2:09
What I asked, what went wrong, how I'd catch it next time. You're done when the log shows patterns and you can name your three most common failure types. The watch-out, fluent is not the same as correct.
2:22
Confident wording is where most mistakes hide. Stage two, staging. Weeks four to six. Now you point AI at your own leadership documents, and you review its output the way you review code.
2:33
Pick three documents you write again and again. A project status update, an incident summary, a quarterly plan. Ask AI for a first draft of each, then review with a checklist. Do the facts match the source?
2:46
Is anything important missing? Does the tone fit the reader? Are risks and edge cases named? And the last line, would I sign my name to this? Note how much you had to fix.
2:57
Keep the prompts that work in a shared note so the team can reuse them. You're done when you know which tasks AI can draft and which need a human first. The watch-out, forwarding a draft upward unedited.
3:09
Your credibility is attached to it. Stage three, production. Weeks seven to ten. This is where you decide where AI belongs in your delivery workflow and write it down. Start with a decision ledger.
3:22
For one workflow, list eight to ten decisions your team makes repeatedly. For each one, who decides today what information they use and what it costs if it's wrong. Then the AI role. Does it suggest?
3:34
Does it decide with sign-off or never? Next, a simple grid. Rate each stage of delivery on two questions. How much would AI help, and how ready are we? Then pick your best candidate and write one runbook card.
3:46
What may it read? What may it change? What must it never touch? How do we notice it's wrong? Who's on call for it, and how do we switch it off? Pilot it with one team for two weeks.
3:57
You're done when one workflow has a ledger, a grid, and a runbook card. The watch-out, automating a decision nobody has ever written down. Stage four, operations. Weeks eleven to thirteen.
4:10
The goal, prove the value, control the risk, and make it official. Measure before and after on the same team. Pick two or three delivery numbers, like review turnaround or change failure rate, plus one quality measure.
4:23
Write a value case with kill criteria. What we expect to improve, how we'll measure it, what it costs, and what makes us stop. Then sort each use into a risk tier. Low, drafts that a human reads.
4:37
Medium touches internal systems. High touches customer data, production, or money. Match the oversight to the tier and to your company policy.
4:44
Name an owner and an on-call path for every agent in use, and then brief your VP. Ten minutes, what you tried, the numbers, what you'll stop, and the policy you propose. The watch-out, measuring speed alone.
4:57
Faster isn't better if quality or on-call load gets worse. Finally, the capstone. Put your ledger, grid, runbook cards, value case, and risk tiers on a single page. Present it to a real stakeholder.
5:10
Note their objections. Revise. That page becomes version one of your team's AI policy, and it's your answer to the question we started with. A few mistakes to avoid, starting with tools instead of decisions.
5:21
Rolling out to the whole org before one team has proven it. Letting an agent run with no owner. Counting output, lines, pull requests as value.
5:30
Skipping the log, then arguing from memory and forgetting your newer engineers. Ask how AI is changing the way they learn. Now your five-minute action. Open a new doc. Call it Team AI Runbook Card Version zero.
5:43
Fill in only two lines, what one AI use on your team is for and what it must never touch. That's it. Five minutes is enough. A rough card that exists beats a perfect one you never start. That is your first spark.
5:58
That's it for this episode. If this was useful, share it with a colleague, and I'd love to hear from you. Which stage are you in, and what's the one thing blocking you?
6:07
You can read the full newsletter at tinybigspark.com. Keep innovating and stay inspired.
Tiny Big Spark: The Engineering Leadership Podcast
Listen on
Apple Podcasts
Apple Podcasts
Spotify
Spotify
Pocket Casts
Pocket Casts
Castro
Castro
Recent episodes
No results found
