But the problem starts when “something” becomes your actual product. When customers are paying. When the product needs to evolve fast. And you realize that the people building your core business... don’t actually work for you.

That’s the moment most founders I talk to are in. Not angry at their agency. Just... ready for something more.

The Problem Nobody Talks About Publicly

If you look at dev agency reviews online, most are actually positive. Founders who had a good experience write about it. But the ones who got burned? They stay quiet. Nobody wants to publicly admit they spent six figures on something that didn’t work out.

So the real stories live in DMs. In “off the record” chats between founders. And what comes up over and over isn’t really about bad agencies... it’s about the gap between what the founder understood was happening and what was actually going on.

I would say this is the core of it. As a non-technical founder, you’re making decisions about something you can’t fully evaluate. The agency sends you a status update, it sounds great. But is it? You genuinely don’t know. And that’s not your fault. You shouldn’t need to read code to know if your product is on track.

This is actually the number one reason founders bring in someone technical on their side. Not to replace the agency. Not to fire anyone. Just to have someone who speaks both languages... who can sit in a technical conversation and then translate it into business impact. Like, “here’s what they’re actually saying. Here’s what it means for your timeline. Here’s what you should worry about, and here’s what’s fine.”

I did a technical audit for a B2B SaaS company, around 5 people, with a dev agency and a couple of “dedicated” engineers on their project. They had daily standups, things seemed to be moving but...

…the software was buggy and launch date was postponed over and over again!

Once I dug in, it was pretty straightforward. The engineers weren’t working with the urgency or ownership you’d expect from people building your core product. They didn’t understood the business nor critical user paths within the software, so they were just closing Jira tickets.

The Moment You’ve Outgrown the Model

There are signs. You start wanting to move faster than the agency’s sprint cycle allows. You want someone who deeply understands both, your codebase and the value you bring to your customers. You want to have a conversation about your product’s future and actually understand what’s realistic.

And to be fair... sometimes the answer is to stay with the agency. If you’re pre-product-market-fit and still figuring out what to build, a flexible agency relationship can totally make sense. But once you know what your product is and customers are paying for it, that’s when ownership starts to matter way more than flexibility.

How I Built a Team From Freelancers Up

A B2B SaaS startup, early millions in ARR, about a half-dozen people. I joined as their CTO. They had engineers from Upwork working “full-time”... I put that in quotes because these were freelancers billing by the hour with time tracking. It worked for a while.

The fear was real though:

“If we change anything, we’ll have downtime. Things will fall apart.”

I get it. When your product is live and customers are paying, the last thing you want is chaos. So I followed a rule I’ve learned the hard way: never break working systems.

I didn’t replace anyone on day one. Instead, I started evaluating. Not just code... the people. Who’s actually delivering? Who takes ownership? Who treats this like their job versus a gig between other clients?

The thing is, changing teams is hard. It’s always hard. But it gets way easier when the reasoning behind the changes is crystal clear. And that only really works with in-house people who see themselves as part of the product, part of the mission. Not contractors billing hours for a project they’ll move on from next quarter.

The engineers who genuinely stepped into that mindset, who showed up consistently and took real ownership... they stayed. They became the core of the new team. The rest were gradually replaced. And yeah, it wasn’t always smooth. There were moments where we were thin, where I had to jump in hands-on to make sure nothing fell over while we were between hires. That’s the part nobody mentions in the clean “we rebuilt the team” narratives.

It takes real work to keep the product stable while you’re changing the people building it.

But we got through it. Under six months, the team went from deploying once a month with a full week of release prep to shipping twice a week. And that’s the kind of change you feel across the whole company... sales can promise features with actual timelines, support can tell customers “it’s fixed” instead of “it’s in the queue.”

From One Team to Multiple Teams

Over time, I didn’t just build a team. I grew it into multiple teams with their own leads.

I found people within the team who could own entire areas of the product. Not just write code, but make decisions, communicate with stakeholders, run their own sprints. That’s when engineering stops being a black box and starts being a real department that product, marketing, and sales can actually work with.

And this is where I realized something about the CTO role that led me to what I do now. Most of what fills a full-time CTO’s week at this stage is stuff that doesn’t need a CTO. Status syncs. Routine decisions. Administrative work. All of that belongs with team leads and product managers.

The work that actually shapes a company’s technical future... architecture decisions, hiring strategy, process design, aligning engineering with where the business is going... that’s where the real outcomes come from. You don’t need someone doing that 50 hours a week. You need someone doing it well, consistently, with deep context.

What the Transition Actually Looks Like

I can tell you, founders always ask me “okay, but what does this actually look like week by week?” So here it is.

First couple of weeks, I audit what you have. Code, infrastructure, team, workflows. Real bottlenecks usually show up in the first few days... the rest is confirming and documenting.

First two months is the rebuild phase. Right people in the right seats, core processes in place. The team goes from shipping unpredictably to having a cadence you can actually plan around.

Months three to six, the team grows. Team leads emerge. You stop being pulled into every technical decision. Engineering starts talking directly to product and sales instead of everything going through you.

After six months... you get updates, not emergencies. The team and the knowledge belong to you. When someone leaves, the codebase and the processes stay.

That last part is what makes in-house different from agency:

The Cost of Waiting

I’m not going to tell you the sky is falling. But I will say this... every month you run with an engineering setup that can’t ship fast, the cost compounds.

Not just in money. In opportunities. Feature your customers asked for months ago that’s still “in the next sprint.” A competitor who launched something similar last week. A bug that’s been “almost fixed” for four weeks.

The companies I work with that are doing well right now... they all have one thing in common. They own their engineering. They’ve got in-house teams using AI tools to move faster, cross-functional workflows where product and engineering actually talk to each other, and a release cadence that lets them respond to market in days, not months.

Looking back at everything I’ve seen over the years, the founders who made the transition earlier always wish they’d done it sooner. And the ones who waited... well, they still got there eventually. It just cost them more.

The Question Worth Asking

If you’re working with an agency or outsourced team right now, ask yourself this: do you understand what’s happening in your own product?

Not “do you get status updates.” Do you actually understand what’s being built, why decisions are being made, and whether you’re on track?

If the answer is “not really”... that’s your starting point.

I’ve spent the last 15+ years building engineering teams in B2B SaaS and martech startups. If you’re thinking about making the transition from agency to in-house, or you’ve got a small remote team that needs structure and speed...

I’ll do a free 1-hour outside opinion with you.

Schedule 1-hour free outside opinion

No code access needed. Just screen share or send me a Loom of your setup, and I’ll tell you honestly what I’d change and whether you actually have a problem worth fixing.

Happy to help: WhatsApp, Calendly, LinkedIn

Last fall, I joined one of the best gyms in town. Black Friday sale, annual membership, the whole deal.

I joined mostly for mental health. There was a lot of uncertainty in my life, lot of ups and downs. Gym helped with that. It always has.

I’ve been going to gyms for years. I know the exercises, I have decent program, I show up 3 times a week. I was doing everything “right.”

And then my 5-year-old daughter seen my wife watch Bridgerton and saw some guy with a six-pack on screen. And she asked me: “Daddy, where is YOUR six-pack?”

I’m like: Hell, yeah. That’s right.

Years of working out. And I never actually set a goal of getting a six-pack.

The Day Everything Changed

Same day, I did the research. Turns out 80% of getting abs happens in the kitchen, not the gym.

So I downloaded a calorie tracking app (one with AI that scans your food - pretty cool - 0xCal), bought iso whey protein, set a target weight, and started calorie deficit.

And here’s the thing... when you have a clear goal, you start seeking out knowledge. A guy at the gym mentioned creatine to preserve strength while cutting. Before, I would have nodded and forgotten. Now I bought it the same day.

I stopped eating snacks, cookies, cakes. Basically stopped drinking alcohol except special occasions. Started weighing myself every day.

But here’s the crazy part: I’m pushing MORE weight in the gym now. Despite eating way fewer calories. Because every rep matters. Every meal matters. There’s a destination now.

Two weeks in, I’ve already dropped a couple of kilograms. And I feel more energized than before, not less.

Same Gym. Different Results.

The thing is, I was putting in effort before. Real effort.

• Going to the gym 3x per week ✓

• Following decent program ✓

• Showing up consistently ✓

But I had no goal. I was just... maintaining. Going through the motions. Working out for the sake of working out.

The moment I set specific target, everything reorganized around it. Not just my workouts - my entire life shifted. Diet, supplements, tracking, focus. Same gym, same equipment, same time investment. Completely different trajectory.

Your Company Is Probably Doing the Same Thing

I see this pattern constantly in the companies I work with.

Teams that are genuinely busy. Genuinely working hard. Daily standups, sprint planning, quarterly reviews, lots of meetings. Everyone’s showing up. Everyone’s working.

But toward what?

When I ask: “What’s your six-pack? What specific outcome are you trying to achieve this quarter?” - often there’s silence. Or answers so vague they could mean anything.

The research backs this up. Businesses with clear goal-setting systems grow 12% faster and make 31% more money. But only 4 out of 10 employees actually understand what their company is trying to achieve.

More than half your team might be working toward... nothing specific.

Busy Is Not the Same as Productive

There’s an outdated mindset in lot of organizations: lots of input equals lots of output equals success. Full schedules and 60-hour weeks get rewarded with appreciative nods.

But busy doesn’t equal productive. Busy often gets in the way.

When you start conversations with “What did you do this week?” you create illusion of progress. Everyone’s always doing something.

When you start with “Did we move closer to our goal?” - suddenly it matters whether those activities produced results.

It’s the difference between “I went to the gym 3 times” and “I lost 2 kilos.”

Lead Metrics and Lag Metrics

This is where simple framework helps.

A lag metric is the outcome. It’s backward-looking - by the time you see it, it’s history. My weight on the scale. Your quarterly revenue. Customer churn rate.

A lead metric is the activity that predicts the outcome. It’s forward-looking - you can influence it directly. My daily calories. Your team’s number of customer conversations per week.

Most companies only track lag metrics. They look at revenue or churn after the fact and wonder why things aren’t improving. Or worse - they track activities without connecting them to any outcome at all.

“We shipped 47 features this quarter!” Great. Did it move the number you actually care about?

The moment you set clear goal, your lead metrics suddenly matter. They’re connected to something real. You can course-correct weekly instead of discovering problems quarterly.

What Actually Changes When People Know the Goal

Here’s where it gets interesting. Concrete example from my work.

When engineers only know “build feature X,” they build feature X. They might overengineer it. They might add complexity that looks impressive but doesn’t matter. They optimize for code elegance because that’s what they can see.

But when engineers know the actual business goal - “we need to reduce churn by 15% this quarter, and this feature is our hypothesis for how” - something shifts.

Suddenly they’re asking different questions. “What if we built simpler version first to validate the hypothesis?” “Do we even need this feature, or could we solve the churn problem differently?” “What’s the fastest path to learning if this works?”

They stop overengineering. They start thinking about validation. They offer alternative solutions you never considered.

Same engineers. Same skills. Same salaries. Completely different value delivered.

The goal changes the conversation.

The Question to Ask Yourself

If you’re running a company or leading a team:

Do you have a six-pack goal? Not a vague mission. Not a list of activities. A specific, measurable outcome you’re working toward this quarter.

Does your team actually know what it is? Not “heard it once in an all-hands” know. Really know.

Are your lead metrics connected to that goal? Or are you just tracking activity for activity’s sake?

I can tell you, employees with clear goals are 8.1 times more likely to actively seek ways to improve their work. That’s not a small difference. That’s a transformation.

Looking Back

Looking back, I could have had a six-pack years ago. All that time in the gym, all that effort, all those workouts... going somewhere, but nowhere specific.

One question from my daughter changed everything. Not because I started working harder. But because I finally knew what I was working toward.

What’s your six-pack?

Things are working. But somewhere between your third “we need this yesterday” conversation and that 11pm Slack message to your developer... you start to feel it. You’re not building a product anymore. You’re firefighting.

That gap between “MVP that works” and “engineering team that scales”? That’s where most startups either level up or get stuck. And it’s exactly where I step in.

What’s Actually Slowing You Down?

When founders come to me, they usually start with the same thing: “Here’s everything I want to build.” Big roadmap. Lots of excitement. But that’s not where we start.

We start with a different question:

What’s the one thing blocking your growth right now?

Think of it like a restaurant that’s suddenly popular. You don’t immediately hire 10 more waiters. Maybe the real problem is the kitchen can’t keep up. Or maybe customers can’t even find a table because there’s no reservation system.

Same thing with your product. Maybe your app crashes when too many users hit it at once... that’s a backend problem (database, everything behind the scenes). You need someone who can build the engine under the hood. Maybe users sign up and leave because the experience feels clunky... that’s a frontend problem (UI/UX, everything the user actually sees and clicks on). You need someone who can make the product feel polished and intuitive.

Or maybe you’re personally approving every technical decision and it’s eating your entire week... and that means you’re the bottleneck, and you need a technical leader.

The bottleneck tells you who to hire first. Not some generic “ideal startup team” template you saw on Twitter or got from ChatGPT.

The Vibe Coding Hangover

Here’s something I see more and more. Founders who built their entire product with vibe coding. Described what they wanted, AI generated the code, and somehow... it worked. They got users. Some even got revenue.

I’ve talked to several founders in exactly this spot. The product is live, traction is real, but the code underneath? It’s like a house that was built in a weekend. It stands, but nobody’s quite sure which walls are load-bearing.

And I get it... these AI tools are incredible. I use them myself every single day. But there’s a big difference between using AI as a power tool and relying on it as your entire construction crew.

If that’s you, get real engineers involved early.

Your job is to be the founder...

…talking to customers, closing deals, steering the ship. Not debugging code at midnight. The engineers I bring in know how to work with AI-built codebases. They figure out what’s solid, clean up what isn’t, and build on top of it properly.

Why I Build Teams in Eastern Europe

You might not know this, but some of the biggest tech products you use every day were built by Eastern European engineers. Grammarly was founded in Kyiv. WhatsApp was built by a Ukrainian-born engineer. GitLab, now a public company worth billions, was co-founded by a developer from Kharkiv. Preply, the language tutoring platform used by hundreds of thousands of students worldwide, started in Ukraine 🇺🇦 too.

I’ve been hiring and leading remote engineering teams in Eastern Europe since 2015. Long before COVID made remote work a thing. I’ve built teams across Portugal, Germany, Poland, Romania, Ukraine, and everywhere in between. Here’s why this works for US-based startups:

You get great people, fast.

There are over 1.2 million developers in Central and Eastern Europe. Many trained at top technical universities, worked at international companies, and are genuinely excellent at what they do. The talent pool is deep, and because I’ve been in this market for over a decade, I know where to find the best people and I can move quickly. While a US recruiter is still screening resumes, I’ve already got candidates lined up.

Your money goes way further.

Compared to US rates, you can save 50-60% on engineering costs. That means you hire 2-3 great engineers instead of one. Or you extend your runway by a year. That’s not cutting corners... that’s being smart with your money.

They’re online when you are.

Eastern Europe overlaps with the US East Coast for over a half the working day, and fully overlaps with Western Europe. You’re not waiting until tomorrow for answers.

English for you, native language for depth.

Your team speaks English in every meeting with you. All-hands, standups, one-on-ones... all in English. But when two engineers need to go deep on a technical problem, they can think and debate in their native language, which means faster, sharper problem-solving. I’ve set up teams where the product manager syncs with developers in their language and reports to the founder in English. Best of both worlds.

And here’s something founders don’t think about until it becomes a problem: the legal and tax side. I speak four languages fluently and I know the contractor regulations across Europe. From Portuguese freelancer laws to German compliance requirements to Ukrainian employment rules. Trust me, you do not want to figure this out on your own while also trying to scale your product.

How I Structure Your Team

Once we know your bottlenecks and who to hire first, the next question is how fast you want to scale.

If you’re early and scrappy, one small team does the job. Two or three engineers and someone product-minded wearing multiple hats. You don’t need a 20-person org chart.

If you’ve raised money and your roadmap is packed, I’d set up two small teams on two separate tracks. Think of it like opening two checkout lanes instead of one long line. Each team is tiny... two, three people... but they move independently and ship fast.

One thing I always make sure of: balance. Every engineer leans either backend or frontend, no matter what their resume says. I’m a backend guy myself... give me a database problem and I’m on it, but ask me to make the UI pixel-perfect? I’ll tell you “it looks fine” when it clearly doesn’t. So I build teams where someone cares about the engine and someone cares about the paint job.

And you need at least one product person watching the market, not just building features. Someone tracking competitors, digging into how users actually behave, making sure engineers build what matters most. Without that, your team is building in the dark.

Here’s How It Works

1. We figure out what you need. Bottlenecks, roadmap, budget. You get a clear plan: who to hire now, in 3 months, and what the team looks like in a year.

2. I find the right people. Engineers who work with AI tools, team leads who run things without you, product people who translate your vision into specs. Best talent, startup-friendly rates.

3. I set up the machine. Team structure, workflows, how code gets shipped, how the team communicates. Not heavy process... just enough so things don’t fall apart when you grow.

4. I run it. As your fractional CTO, I lead engineering so you focus on the business. I’m in the code every day, I know what’s shipping, and I bridge your business goals with what actually gets built.

Here’s What’s At Stake

Looking back at all the founders I’ve worked with... this transition from scrappy MVP to real engineering org is where startups win or lose time they can’t get back.

Some founders over-hire and burn through their cash too fast. Some under-hire and burn themselves out trying to do everything. Some hire the wrong people and lose an entire quarter figuring that out.

I’ve made these mistakes myself earlier in my career. And I’ve helped enough founders avoid them that I know exactly what the playbook looks like.

If you’ve got product-market fit and you’re thinking about building a real engineering team...

WhatsApp me!

…shoot me a message on WhatsApp for a quick free call, or just send me an async question. Let’s just figure out what makes sense for where you are right now.

Happy to help: WhatsApp, Calendly, LinkedIn

But I’d never actually ran my own ads. Never spent my own budget. Never stared at a campaign dashboard wondering if I just lit money on fire.

Until now.

Why Ads? Why Not Just Get Referrals Like Everyone Else?

Here’s the thing. Most fractional CTOs get their clients through referrals. And the data backs it up... 90% of fractional executives rely on their network for new clients. Only 13% use paid advertising.

And sure, I’ve got a solid network across the US and Germany. But referrals have a cold start problem. Even with a big network, you’re just waiting for someone to think of you at the right moment.

Cold outreach works too, I’ve learned that from other fractional CTOs. But it requires serious dedication and way more patience than I had. You’re playing the long game.

I wanted results faster. Not because I need 100 customers. I want max 3-4 simultaneously. But I want them to be a perfect match. The kind of engagement where my expertise creates real impact and where there’s room for upside beyond just billing hours.

So I went with Meta ads.

The Setup: Where MarTech Experience Pays Off

This is where being a tech person running their own ads gets interesting.

Most founders launch Meta ads with the basic tracking snippet and hope for the best. The problem? Ad blockers and iPhone privacy settings silently eat 30% of your data. You’re making budget decisions on incomplete information without even knowing it.

So I set up a proper tracking stack. In plain English: I made sure the data reaches Meta through two independent channels instead of one, with safeguards so nothing gets counted twice. On top of that, I added my own analytics layer to see the full picture... not just what Meta chooses to show me.

For the more technical folks, here’s the breakdown:

• Client-side Meta Pixel for browser-based tracking

• Server-side Conversions API (CAPI) that bypasses ad blockers and iOS privacy restrictions

• Event deduplication so Meta doesn’t double-count conversions when both channels fire

• Reverse proxy routing tracking through my own domain for higher data quality

• PostHog tracking every single step in the pipeline, from first click to conversion

If this sounds like the kind of setup you need, WhatsApp me.

If you haven’t heard of PostHog... think of it as an open-source alternative to tools like Google Analytics plus Mixpanel or Amplitude. I use it to see exactly what happens after someone clicks my ad.

And here’s the AI part... I built the dashboards using AI. There’s a thing called PostHog MCP that basically lets AI tools plug directly into services like PostHog and talk to them. So instead of spending hours manually clicking through dashboard builders, I described what I wanted to see in plain language and AI generated the dashboards for me. That’s the kind of leverage AI gives you when you know what to ask for.

The Experiment: 4 Pains x 2 Formats

I launched with a structured test. Four different pain points that SaaS founders typically face, each in two formats: image and video. Eight ad variations total, all driving to my website.

Started with broad audience targeting since it often outperforms micro-targeted campaigns. The algorithm finds patterns you’d never think to target manually.

Then I watched who engaged with what.

And here’s what I learned: my funnel was too generic to cover all four pains effectively. But that’s exactly the point of running the experiment. Now I know which pain resonated the most and which audience to narrow down on.

I also learned that broad targeting can backfire. My ads were getting a lot of attention from developers instead of the founders and CEOs I was actually trying to reach. So I narrowed down the targeting. Lesson learned: clean data signals help the algorithm, but you still need to tell it who you’re talking to.

One topic in particular sparked a lot of reactions... good and bad... among founders and devs. Highly risky, kind of nasty topic. But well, that’s me. I like sparking emotions and challenging beliefs for good. More on that in upcoming posts.

The Consultant Move: AI Can’t Replace This

I hired a consultant to help me set things up right. Campaigns, ad sets, budget limits, optimizing for leads vs. first meaningful contact.

And here’s something I’ve learned recently as a good habit:

Always bring in a human expert, even when you’re capable yourself.

Sure, you can ask AI for campaign structure advice. I literally build AI integrations for a living. But here’s what AI can’t do... it can’t stop you from freaking out when your first $300 disappears with zero results. It can’t talk you off the ledge when you’re about to kill a campaign too early. It can’t share that gut feeling from having managed thousands of campaigns.

Human relationships and emotions are priceless. AI is an incredible tool for execution and analysis. But the human element... the reassurance, the pattern recognition from years of experience, the ability to say “relax, this is normal, give it three more days”... that’s something no model can replicate.

I use AI to build dashboards, generate tracking code, analyze data patterns. I use humans to make better decisions under pressure.

What’s Next

I’m starting a blog series on the topics that resonated in my ads. The ones that sparked debate, made people uncomfortable, got founders thinking differently.

But I’m also gonna explore every channel. Not because I need dozens of clients. Because I want every client to be a perfect match. The kind where I know I can actually move the needle.

For the ones who aren’t a perfect match with me personally? I’m building relationships with other fractional leaders I can confidently recommend.

Because doing right by people matters more than closing a deal.

Looking back, the biggest surprise wasn’t the technical setup. That part I knew. It was how different it feels when it’s your own money, your own brand, and your own future on the line.

Well, stay tuned.

WhatsApp me!

If you’re a founder dealing with any of this, happy to help: WhatsApp, Calendly, LinkedIn

So you triple the team.

Here’s what nobody tells you: your output won’t triple. It probably won’t even double. And if you rush it? Your velocity might actually drop.

The benchmark: If you go from 5 to 15 engineers, doubling your output would be a good result. Tripling? That would be outrageous. Most teams don’t even get close.

I’ve scaled teams multiple times. And I’ve watched inexperienced managers make this exact mistake over and over.

Brooks’s Law: The Classic Trap

This problem has a name. Back in 1975, Fred Brooks wrote The Mythical Man-Month and coined what’s now called Brooks’s Law: “Adding manpower to a late software project makes it later.”

Why? Two reasons.

First, new people need ramp-up time. They need to learn the codebase, ask questions, get code reviews. During this time, they’re not just unproductive... they’re actually pulling your existing team away from their work.

Second, communication overhead grows exponentially. A team of 5 has 10 communication paths. A team of 15? That’s 105 paths. Every additional person makes coordination harder.

Brooks called it an “outrageous oversimplification,” but decades of research have validated the core insight. Studies consistently show that teams over 9 people are significantly less productive per person than smaller teams.

The Math That Kills Your Roadmap

Let’s say you have 5 engineers. They’re great. They know the system in and out, they wrote it themselves. Now you hire 10 more over next months.

Skip the onboarding. That’s a few weeks to a month, fine.

But then what happens?

Your original 5 engineers stop coding.

Or at least, they code way less. Some of them become team leads. Engineering managers. They’re now spending time on people stuff instead of building features. The same people who knew every corner of your codebase? They’re now in meetings.

Your new hires can’t debug like the originals.

Those new 10 engineers haven’t written the code. They don’t know the edge cases. They haven’t learned why that weird function exists. It takes months... sometimes 6 months or more to get truly deep into a complex system.

And here’s the killer: collisions.

The amount of handoffs. Merge conflicts. People stepping on each other’s toes. Every additional person adds communication overhead.

You know that question you always ask your CTO: “Why is this taking so long?”

This is why.

The 9 Women, 1 Baby Problem

Here’s the thing. You cannot give birth to a baby in one month with 9 women. That’s not how it works.

But 9 women can give birth to 9 babies.

Same logic applies to software. If you have 5 people working on 2 features, adding 10 more people to those same 2 features won’t make them ship 3x faster. You’ll just have 15 people tripping over each other.

How I Actually Scaled Without Losing Velocity

With this logic, I scaled my team from 5 to 15 without losing a single bit of productivity.

The secret? No collisions.

Coming from an engineering background myself, I did this intuitively at first. Don’t have people working on the same thing. No coordination overhead. No conflicts. No merge hell.

In practice, this meant 1-2 people per feature, balanced by stack (front-end and back-end). But the exact number doesn’t matter. What matters is that people aren’t stepping on each other.

Only later, when I started researching why this worked, I realized I was applying what’s called modular design in software architecture. The same principle that makes good code... makes good teams. Reduce dependencies. Create clear boundaries. Let each unit operate independently.

It worked. The scale initially worked really well.

But then the bottleneck shifted.

The Bottleneck Always Moves

First it moved to product management. We had a big pipeline planned out, so we survived for a while.

But then ownership became the problem.

We had features. We had people. No conflicts between features. But... how is the feature connected to the product? To the market? To what customers actually need?

This is where gaps showed up.

The engineers were just taking tickets and implementing them. They didn’t understand why the feature mattered. They couldn’t make smart tradeoffs. They weren’t adding analytics by default. They weren’t thinking about the business.

So the next level was engaging engineers in co-ownership. Not just “take the feature, implement it, done.” But actually understanding the business value of what they’re building.

When product management was the bottleneck, engineers who understood the business could still move forward. They could add the right tracking. They could make smart decisions without waiting for specs.

The Ratios Nobody Talks About

Here’s something most founders miss: you can’t just add engineers. You need to maintain ratios.

Product-to-dev ratio. If you have 15 engineers but only 1 product person defining what to build, you’ll have 10 engineers waiting around or building the wrong things. The industry standard is roughly 1 product manager per 5-7 engineers for complex B2B products. You need enough product capacity to keep your engineering team busy with validated, meaningful work.

The senior-to-junior balance. If you hire 10 juniors and expect your 2 seniors to mentor all of them while still shipping... good luck. The seniors become full-time teachers and your velocity tanks.

Management span. One manager can effectively handle 5-8 direct reports. If you go from 5 to 15 engineers, you need at least one more layer of management. That’s another person who used to code and now doesn’t.

The 10-engineer threshold. Once you hit around 10 engineers, you need to start thinking about breaking them into separate teams. That’s where the direct reports limit kicks in. One person simply can’t effectively manage more than that. At some point I had to do exactly this... split the group into smaller teams with their own leads. Otherwise you end up with a manager who’s stretched too thin and engineers who don’t get the attention they need.

How Long Does This Actually Take?

This is something I’ve done consistently, so I can speak to my own pace here.

If you do it right and go aggressive, you can nail this scale in a quarter.

At a sustainable pace, half a year.

If you’re busy with other things along the way and can’t give it full attention and hire gradually, expect it to take up to a year before the team is truly humming.

The mistake is expecting the new team to perform at full capacity in month two. It won’t happen.

What This Means for You

If you’re a founder thinking about scaling your dev team from 5 to 15... or 15 to 50... there’s no single answer.

It depends what stage you’re at and your current needs.

Behind on features and need to ship faster?
Hire people. But make sure they’re working on independent things. No overlap. No collisions. That’s how you get actual velocity gains.

Looking for product-market fit?
Don’t scale aggressively. You don’t need 15 engineers building the wrong thing faster. Keep the team small and iterate quickly.

Need better strategy and market fit?
That’s not a hiring problem. That’s about training your existing team. Making them collaborate more. Involving them in product decisions early. Teaching co-ownership so every engineer thinks about business impact, not just code.

The Real Question

Before you hire those 10 new developers, ask yourself:

• Do I have enough independent features to give them?

• Will my senior people become managers and stop coding?

• Do I have the product pipeline to keep 15 people busy with meaningful work?

• Do I have the right ratios (product, senior/junior, management)?

• Will my current bottleneck just move somewhere else?

There’s always a trade-off. You’re managing bottlenecks, basically. Moving them from place to place. Engineering bandwidth. Product clarity. Market understanding. Co-ownership.

The question isn’t “should I hire more?” The question is “what’s my actual bottleneck right now?”

WhatsApp me!

I’ve been in tech for 20 years. 7 years as a CTO, before that an engineering manager, before that an engineer. Building teams, scaling them, coaching founders through exactly this problem.

If you’re facing this challenge, reach out.

AI coding tools are everywhere now. Cursor, Claude... your developers are probably using them already. And the thing is, they actually work. I’m talking 30-40% faster at the individual level. That’s real.

I wrote before about how I got 90% of my engineers using AI daily. Getting adoption was step one. But here’s what I’ve learned since: adoption isn’t the same as results.

Most teams I talk to aren’t shipping faster. They’re generating more code, sure. But their roadmap? Still stuck. Customers still waiting for features. What’s going on?

The Bottleneck Moved

I would say this is the biggest insight I’ve had working with teams adopting AI: the constraint isn’t where it used to be.

Before AI, the constraint was writing code. Developers spent most of their time implementing stuff.

After AI? The constraint is everything else. Code review queues back up. QA gets overwhelmed. And here’s the kicker... developers spend more time debugging AI-generated code than they saved generating it.

It’s like giving everyone faster cars but keeping the same narrow highway. You just get bigger traffic jams.

The teams actually shipping faster? They’ve widened the highway.

What the Winning Teams Do

I’ve been studying this obsessively. And there’s a clear pattern.

They Front-Load the Thinking

The best teams have figured out something powerful: AI is exceptional at implementation when you give it clear specs.

Think about it. AI is like having an incredibly fast developer who needs precise direction. Vague tickets produce vague results. But detailed specifications with clear acceptance criteria? That’s where AI shines.

So the winning teams flipped the model. They spend way more time on specs, way less on implementation. The spec becomes the product. Code is just the output.

I’ve seen teams cut their cycle time in half doing this. Not because AI wrote code faster... but because they stopped building the wrong thing.

They’ve Redesigned Review

When AI generates code 5-10x faster, your review process becomes the bottleneck. Smart teams adapted:

• Tiered reviews: auto-approve low-risk changes, focus human attention where it matters

• AI-assisted scanning: use AI to catch issues before human reviewers see the code

• Smaller chunks: break work into pieces that flow through quickly

Without this? Your senior engineers drown in review queues. I’ve seen it happen.

They Track Different Metrics

Story points are kind of meaningless now. One team completed 150+ points in a sprint after adopting AI tools. But customers didn’t see features any faster.

What actually matters:

• Cycle time: from starting work to customers seeing it

• Lead time: from request to production

• Deployment frequency: how often you’re shipping

These tell you if AI investment is translating to customer value. And you don’t need to understand the technical details to track them.

The Questions I’d Ask

If I was a non-technical founder looking at my engineering team right now, here’s what I’d want to know:

“What’s our cycle time?” If they can’t answer clearly, that’s a red flag. Teams capturing AI’s value know this number. And it’s going down.

“How have we adapted our processes for AI?” The right answer involves specific changes. Not “we installed Copilot.”

“What specs exist before developers start building?” If the answer is just Jira tickets... you’re probably getting inconsistent output.

“What’s our deployment frequency compared to six months ago?” If AI is working, this should be going up.

You don’t need to understand the technical details. You need to ask better questions.

Why This Matters Now

Here’s the thing. AI coding tools are still early. Most companies are experimenting, not optimizing.

The founders who figure this out first, who build engineering organizations designed to amplify AI... they’ll compound that advantage. Ship faster today means more customer feedback, more iterations, more product-market fit.

Your competitors are adopting AI. The question is whether you’ll capture its potential faster than they do.

What I Help With

Unlocking AI’s full potential isn’t a tools problem. It’s an organizational design problem.

• Process architecture that puts AI in the right place

• Metrics that connect engineering to business outcomes

• Team development that builds AI fluency

• Strategic oversight so AI investment actually translates to shipping faster

This is what I do as a fractional CTO. Not adding headcount. Unlocking the team you already have.

If you’re a non-technical founder and some of these questions made you uncomfortable... let’s talk.

Book a call

I offer a free 30-minute call for non-technical founders who want to figure out where they stand. No pitch, just an honest look at your setup.

I’ve never done an Agile transformation. Not because I don’t believe in Agile principles. I do. But “transformation” is just the wrong word for what actually works.

Early in my career, I was involved in a massive product rewrite. The work was hidden from reality, from real customers, for about a year. Engineers built feature after feature in isolation, convinced they were making progress.

Then we shipped.

That’s when real work has begun. Critical paths broke. Assumptions crumbled. Everything we thought we knew had to be renegotiated with reality. A year of “progress” became months of painful course correction.

That experience taught me something I’ve applied to everything since. Work needs to be confronted with reality as soon as possible, in small meaningful steps.

This applies to code. It applies to products. And it absolutely applies to how you change a team’s process.

The Problem with Big Bang Transformations

When someone hires an Agile consultant to “transform” their team, here’s what usually happens:

1. Consultants arrive with a framework

2. Everyone gets trained on new terminology

3. Existing workflows are ripped out

4. New ceremonies are installed

5. Team spends months fighting the process instead of doing the work

6. Consultants leave

7. Team quietly reverts to what actually works

I’ve seen this pattern destroy trust and kill momentum. Teams don’t resist change because they’re stubborn. They resist because they know something the transformation plan doesn’t account for. Context matters.

Every team has invisible load-bearing walls. Rip them out without understanding what they support, and the whole thing collapses.

What Works Instead

I was always a fan of changing things step by step. Evaluate. Adjust. Let the process emerge naturally from real friction rather than from a book.

The thing is, most teams are already doing some version of good practice. They just don’t have names for it.

My approach is to apply one principle or pattern at a time. And to stitch it into the existing workflow, not replace it. The framing I use sounds like this:

“We’re doing this anyway. Now it’s just a little more structured and guided.”

That’s it. No revolutionary manifestos. No burning the boats. Just: this thing you’re already doing? Let’s make it more intentional.

A Concrete Example

Say a team has some informal way of tracking work. Maybe it’s a spreadsheet. Maybe it’s Slack threads. Maybe it’s just “everyone kind of knows what they’re working on.”

Step one isn’t “implement Kanban.” Step one is add a proper board that reflects what people are actually doing. See my other related post here:

Then you coach on one principle: move things from left to right as fast as possible. Not “finish as many tickets as you can.” Not “maximize velocity.” Just: whatever you start, finish it before starting something new.

Then you observe. What’s getting stuck? Why? Does it need an additional status? A handover? A review step? Someone to unblock it?

The process reveals itself through friction. Your job is to notice the friction and give it structure. Not to impose structure and hope it reduces friction.

Why This Works

Big transformations fail because they treat process as something you install. But process isn’t software. You can’t deploy it and walk away.

Best process emerges from real friction.

When you change things incrementally:

• Team understands why each change exists

• Changes that don’t work can be reversed without drama

• You build trust instead of burning it

• Reality tests your assumptions continuously

When you do a big bang transformation:

• No one understands why anything is the way it is

• Reverting feels like admitting failure

• Trust erodes with every imposed ceremony

• You find out what’s broken only after everything’s broken

The Engineer’s Mindset

Looking back, I never made the mistake of doing a big bang transformation. I was intuitively doing the right thing from the beginning. But I didn’t learn it from management books.

I learned it from building systems.

That failed product rewrite taught me that hiding work from reality is always a mistake. Ship small. Get feedback. Adjust. Repeat. The longer you wait to confront reality, the more painful the confrontation will be.

Process change is the same. Each change should be small enough to evaluate, meaningful enough to matter, and reversible enough to survive being wrong.

Subscribe now

The Bottom Line

If someone asks me to do an Agile transformation, I say no.

If someone asks me to help their team work better, I say:

That’s not as exciting as a transformation. It doesn’t come with a certification or a framework diagram. But it actually works.

Because the goal was never to do Agile. The goal was to build better products with less pain.

And that happens one small, meaningful step at a time.

I know, I know. Another process guy. But hear me out.

Why I Push This So Hard

On one hand it’s about protecting engineers. You know the pattern - PM pings someone on Slack: “Hey, quick question, can you just look at this thing?” Three days later that engineer is still on it while their actual sprint work rots. Sales sends a “critical bug” directly to whoever responds first. Marketing needs a “tiny change.”

Without a forcing function, engineers become victims of whoever has the loudest voice. Jira isn’t bureaucracy here - it’s protection. It gives everyone the right to say: “Happy to help. File a ticket and we’ll prioritize it.”

On the other hand, it prevents the “what the hell is he doing” frustration. I’ve been in those meetings. A stakeholder asks when something is shipping. You turn to your team and get vague answers. “Soon.” “We’re working on it.” When stakeholders can’t see what’s happening, they fill the void with anxiety. They start interrupting engineers for status updates. They escalate.

The rule isn’t surveillance. It’s transparency. And transparency creates autonomy - when people can self-serve their status updates, they stop interrupting your team.

The Data Behind This

On protecting engineers from interruptions:

Gloria Mark’s research at UC Irvine found it takes 23 minutes to refocus after an interruption. Sophie Leroy at University of Washington calls this “attention residue” - part of your brain stays stuck on the previous context. The more engaging the interrupted task, the worse it gets.

Five interruptions a day? That’s two hours of lost focus. Every day. Studies estimate context switching can reduce productivity by up to 40%. Interrupted tasks take twice as long to finish and contain twice as many errors.

On transparency reducing overhead:

The Project Management Institute found that 56% of project failures cite ineffective communication as the primary cause. When stakeholders can’t see what’s happening, they fill the void with meetings, Slack pings, and escalations.

When everyone sees progress as it happens, status meetings become lighter - or disappear entirely. Managers who know what’s happening without asking can focus on decisions instead of chasing updates.

The Early Stage Exception

Of course, if you’re an early stage startup with few devs, skip all that and just keep things rolling. Those engineers have a product-mindset anyway. They’re talking to customers, shipping daily, small enough that coordination happens naturally.

But 10 people and beyond? Things get messy without clear processes and Jira hygiene.

The complexity of coordination scales with team size. Four people have 6 communication channels. Ten people have 45. Twenty people have 190. Without structure, information loss becomes inevitable.

“Just Fix Culture” Doesn’t Work

Haters might say, you just need to fix culture or motivate people. But I’ve been there - highly motivated team, excellent people who genuinely care about the product.

And you know what? Until it’s a habit, hygiene slips.

Because motivation doesn’t create habits. Passion doesn’t override human cognitive limits. Even the most dedicated engineer will forget to update a ticket status when they’re deep in debugging. Even the most diligent PM will slip on documentation during a crisis.

Hygiene isn’t about motivation. It’s about systems. And systems only work when they’re mandatory.

One Hacker News commenter captured the anti-process view: “Tickets in Jira are not the work itself - it is a LARP of the work. Fixing a bug without filing a Jira ticket is in itself progress. Moving a Jira card without any other change is not.”

And they’re right - the ticket isn’t the work. But the ticket enables the coordination of work. And in any team larger than a few people, coordination is the bottleneck, not individual execution.

What I Actually Saw Work

I saw this play out - and the research backs it up.

Less frustration on both ends.

The American Institute of Stress found that 80% of employees report “productivity anxiety” - the constant feeling they should be doing something else. The cure? Clear priorities. When engineers see exactly what’s expected, they stop second-guessing. When stakeholders see progress without asking, they stop pinging.

Gallup reports that 41% of employees experience high daily stress, with unclear expectations being a major driver. A shared backlog fixes this for everyone - assignees know what to work on, reporters know where their request stands.

Better strategy and prioritization.

You can’t prioritize what you can’t see. Professor Paul Nutt at Ohio State found that 50% of strategic decisions fail - but structured visibility into work improves success rates to 80%.

When all work lives in one place, leadership stops guessing. They see what’s actually consuming engineering time. They make trade-offs based on reality, not whoever yelled loudest in the last meeting.

The Anti-Patterns to Avoid

Let me add - doing this wrong is way worse than not doing it at all.

Over-engineering workflows is the biggest mistake. Complex state machines with multiple approval gates don’t enable agility - they codify bureaucracy.

Required fields backfire. When every ticket demands ten mandatory fields, users fill in garbage data just to satisfy the system. If a field must be required, always include an “I don’t know” option.

Using Jira as communication tool creates fragmentation. Teams add notes, tag each other, hold conversations in comments instead of having actual discussions. Jira is a system of record, not Slack replacement.

Looking Back

After a decade of pushing this rule, here’s what I can tell you.

The teams that resist process the loudest are usually the ones drowning in coordination overhead. They just don’t see it. It’s death by a thousand Slack pings.

The teams that embrace visibility - even grudgingly at first - eventually become its biggest advocates. Because they discover something: when everyone knows what everyone’s working on, trust increases. The need for meetings decreases. Engineers actually enjoy their tools.

Both camps have valid points. Heavy process without purpose creates waste. Absence of discipline creates chaos. The path is narrow - hard limits that force prioritization while keeping signal-to-noise ratio high.

Is it unpopular? Sometimes. Does it work? Every single time.

Subscribe now

What’s your experience? Do you enforce ticket hygiene or think it’s process theater? Drop a comment.

“Yeah, we bought licenses. Engineers can use it if they want.”

Then I ask: “How many actually use it daily?”

Crickets.

Here’s the thing: buying AI tools and getting engineers to actually adopt them are two completely different problems.

We ditched GitHub Copilot a long time ago, by the way. It was fine for autocomplete, but the game has changed. Now we’re using Cursor for frontend work (it’s great for React and component stuff), Windsurf for backend (it’s okay, gets the job done), and Claude Code for everything else.

And honestly? Nothing beats Claude Code. The agentic workflow, the ability to actually understand context across your whole codebase, the way it handles complex refactoring => it’s on another level. But I’ll get to that.

I spent the last 6 months actively pushing AI adoption across my engineering team. Not just “making it available.” Actually pushing it.

And I’m seeing results. Real usage. Productivity gains. Engineers who were skeptical are now telling me they can’t work without it.

Here’s how I did it.

The Problem With “Making It Available”

Most companies approach AI tools like this:

1. Buy licenses for GitHub Copilot or Cursor or whatever

2. Send an announcement: “Hey team, we now have AI coding tools available!”

3. Wait for adoption

4. Wonder why nobody’s using it

I did this too at first. And you know what happened? Maybe 2 out of 15 engineers actually used it consistently.

Why?

Engineers have workflows that already work.

They’re busy. Learning a new tool, even one that could save time, requires upfront investment.

Without active encouragement, most people default to what they know.

Skepticism is real.

A lot of senior engineers (especially the ones who’ve been coding for 10+ years) are skeptical of AI. “It just autocompletes. I can type fast enough.” “The suggestions are wrong half the time.” “I don’t trust it for production code.”

These aren’t dumb concerns. They’re just... incomplete. Because they haven’t experienced the productivity boost yet.

Nobody’s measuring it.

If you don’t track usage, you don’t know who’s benefiting and who’s not. You can’t spot patterns. You can’t help the people who are struggling.

You’re just hoping for the best.

My Approach: Active, Persistent, Measured

I decided to treat AI adoption like any other initiative: with intention, follow-through, and metrics.

Here’s what I actually did.

1. Push It Everywhere (In Slack, Meetings, 1-1s)

I started talking about AI coding tools constantly.

In Slack:

• When someone shares a cool feature they shipped, I ask: “Did you use Claude Code for any of this?”

• When someone’s stuck on a problem, I suggest: “Have you tried throwing it at Claude Code? It’s scary good at debugging.”

• I share my own wins: “Just used Claude Code to refactor 500 lines of code in 10 minutes. It understood the whole context. Game changer.”

In meetings:

• During sprint planning: “Remember, you’ve got AI tools now. Use them for boilerplate.”

• During retros: “How many of you used AI this sprint? How’d it go?”

• During tech talks: I demo specific workflows with AI

In 1-1s:

• I ask every engineer: “Are you using Claude Code yet? What’s your experience?”

• If they say no, I ask why. If they say yes, I ask what’s working.

• I troubleshoot with them. “Not getting good results? Let me show you how I structure my prompts.”

The key: constant, low-pressure reminders.

Not “you MUST use this.” More like “hey, this is available, it’s really useful, here’s how I use it, give it a shot.”

But consistently. Every week. Multiple times.

Here’s what I noticed: active pushing plus genuine exchange sparks interest. When engineers see you actually using it, share their own discoveries, ask questions! That’s when it clicks. That curiosity is the foundation.

Once you have interest, you can move to the next level: establishing standards, building shared assets (prompt libraries, custom instructions), and adjusting processes to actually leverage AI properly.

2. Get Team Leads to Push It Too

Here’s the thing: I can only influence so much.

So I got my team leads on board.

I told them: “Part of your job now is helping your stream adopt AI tools. Encourage it. Share tips. Ask about it in standups.”

And they did.

Suddenly, it wasn’t just me. It were multiple people consistently talking about AI adoption.

That social proof matters. When multiple people are using it and talking about it, it normalizes the behavior.

3. Set Up Team Accounts (And Monitor Usage)

This was a game-changer.

I set up team accounts for our AI tools. This lets me:

• Track who’s using the tools and how often

• See usage patterns (are people trying it and dropping off? Or sticking with it?)

• Identify who’s not using it at all (so I can follow up)

I’m not spying on engineers. I’m not micromanaging. But I AM paying attention.

If someone hasn’t logged in for 2 weeks, I’ll ask: “Hey, I noticed you haven’t touched Cursor lately. Is something not working? Or just haven’t had time to try it?”

Usually, it’s one of two things:

• They forgot it was available

• They tried it once, had a bad experience, and gave up

Both are fixable with a quick conversation.

4. Prepare Workshops

Here’s what I learned: most engineers don’t know how to use AI tools effectively.

They think it’s just autocomplete. Or they don’t know how to prompt. Or they don’t know which tools to use for what.

So I started preparing workshops.

Short, practical sessions:

• “How to use Cursor for refactoring”

• “How to use ChatGPT for debugging”

• “Prompt engineering for code generation”

• “When AI is helpful vs when it’s not”

The goal: lower the barrier to entry. Show people the patterns that work.

Not theory. Just: “Here’s what I do. Here’s what works. Try it.”

5. Hire AI-First Engineers

This is the long game.

When we’re hiring now, I ask candidates: “Do you use AI coding tools? Which ones? How do you use them?”

If they say no? That’s not an automatic disqualifier. But it’s a signal.

If they say yes and can talk about their workflow? That’s a big plus.

I want engineers who are already comfortable with AI. Who see it as a tool, not a threat. Who are excited about productivity gains.

And when these people join the team, they bring that mindset with them. They model the behavior for everyone else.

What’s Actually Working

Alright, so what are the results?

Usage is up.

6 months ago: 40% engineers using AI regularly
Now: 90%

That’s a huge shift. And it happened because of active pushing, not passive availability.

Engineers are reporting productivity gains.

I’m hearing things like:

• “Claude Code just wrote the entire feature. I reviewed it, made two tweaks, done.”

• “I threw that async bug at Claude Code. It found the race condition in 30 seconds.”

• “Cursor’s great for frontend stuff, but for anything complex I just open Claude Code now.”

These aren’t juniors. These are senior engineers who were skeptical 6 months ago.

The thing about Claude Code specifically: it actually understands your codebase context. It can reason about architecture. That’s what converted the skeptics.

The culture is changing.

It’s becoming normal to use AI. Engineers share tips in Slack. “Hey, I found this cool Claude Code workflow for...” or “Check out this Cursor trick for components...”

That’s the shift I wanted. From “this is weird” to “this is just how we work now.”

The Resistance I Hit

Not everything has been smooth.

Some engineers are still skeptical.

Especially the most senior ones. They’ve been writing code for 15+ years. They’re fast. They know the patterns.

For them, AI feels like unnecessary overhead. “I can write this faster than I can prompt for it.”

I don’t force it. But I do encourage: “Just try it for one sprint. If it doesn’t help, drop it.”

Usually, they come back and say: “Okay, it’s actually useful for [specific thing].”

Some engineers had bad initial experiences.

They tried Copilot once. It gave terrible suggestions. They gave up.

That’s actually why we moved past Copilot. It’s fine for autocomplete, but when engineers tried it for real work and got garbage, they wrote off AI tools entirely.

Claude Code changed that. When I showed them what agentic AI can actually do, that’s when the lightbulb went on.

This is where the workshops help. “Here’s how to structure prompts. Here’s when to use Cursor vs Claude Code. Here’s what to ignore.”

Some people worry about code quality.

“What if the AI writes buggy code and I don’t catch it?”

Fair concern. My response: “You’re still reviewing it. You’re still testing it. AI is a junior developer that types really fast. You wouldn’t merge a junior’s code without review, right?”

That usually lands.

The Big Picture: AI Is a Competitive Advantage

Here’s why I’m pushing this so hard.

AI tools make good engineers 2-3x more productive.

Not for everything. But for a lot of things: boilerplate, refactoring, test writing, debugging.

If my team is 2x faster on 30% of their work? That’s a massive productivity gain.

Companies that adopt AI early will outpace those that don’t.

AI-assisted coding is already becoming table stakes. The companies that figure it out now have a head start.

Engineers who resist will fall behind.

I don’t mean that in a threatening way. I mean: the engineers who learn to work with AI will be way more productive than those who don’t.

And over time, that gap will widen.

I want my team on the right side of that gap.

What I’d Do Differently

Looking back, here’s what I’d change:

Start with a small pilot group.

Instead of pushing to the whole team at once, pick 3-4 engineers who are enthusiastic. Get them fluent. Then let them evangelize.

Social proof from peers is way more powerful than pressure from management.

Track specific metrics.

I’m tracking usage (who’s logging in). But I wish I’d tracked outcomes: “How much time did this save?” “How many lines of AI-generated code made it to production?”

Hard to measure, but useful for making the case.

Invest in prompting skills earlier.

The engineers who are getting the most value are the ones who learned how to prompt well. I should’ve taught that upfront.

It’s a skill. And it’s learnable.

The Playbook

Alright, so if you want to drive AI adoption on your team, here’s what I’d recommend:

1. Pick the right tools (this matters more than you think)

Skip Copilot, it’s yesterday’s news. Here’s what’s actually working for us:

• Claude Code for everything complex. Agentic AI that understands your whole codebase. This is the game changer.

• Cursor for frontend work. Great for React, component stuff, quick iterations.

• Windsurf for backend if working with JetBrains. It’s okay, gets the job done.

Get team licenses. Make it easy.

2. Push it actively and consistently

In Slack. In meetings. In 1-1s. Don’t just announce it. Keep talking about it.

3. Get your leads on board

They multiply your influence. If they’re pushing it too, adoption happens way faster.

4. Track usage

Set up team accounts so you can see who’s using it and who’s not. Follow up with people who aren’t.

5. Run workshops

Teach people how to use the tools effectively. Show patterns that work.

6. Hire AI-first

When you’re hiring, prioritize candidates who already use AI. They’ll bring the culture with them.

7. Be patient but persistent

This won’t happen overnight. It’s a culture shift. But if you keep pushing, it’ll stick.

8. Build the next layer: standards, shared assets, process adjustments

Once you have adoption, go deeper:

• Create shared prompt libraries for common tasks

• Build custom instructions or CLAUDE.md files for your repos

• Adjust your code review process (AI-generated code still needs review, but maybe differently)

• Establish standards for when to use which tool

This is where the real leverage comes from. Individual adoption is step one. Team-wide integration is where it gets interesting.

Bottom Line

AI coding tools are here. They’re not going away. They’re only getting better.

The question isn’t “should we use them?” It’s “how fast can we adopt them?”

For me, the answer is: as fast as possible.

Because the teams that figure this out now will have a massive advantage.

And I want my team to be one of them.

Looking back on the last 6 months, the biggest lesson is this:

Passive availability doesn’t work. Active pushing does.

If you want your team to adopt AI, you have to drive it. Consistently. Persistently. With intention.

It’s worth it.

Are you pushing AI adoption on your team? What’s working? What’s not?

WhatsApp me!

Happy to help: WhatsApp, Calendly, LinkedIn