AI adoption and
the upskilling default

It strikes me that it’s somehow obvious to everyone that “AI adoption” is a thing every company should care about across their organization. But that was never true for “engineering training.”

It was maybe slightly more true for automation training. Zapier, Make, n8n, etc. But nobody seemed to think every employee needed to become an automation wizard either.

We seemed pretty comfortable assuming that teaching everyone to code would take too long, cost too much, and have too little to do with most people’s jobs. Now we seem comfortable assuming that getting everyone good at AI must be worth the investment. A new line item from the clouds just sort of exists.

After living and breathing AI 24/7 for the past two years, I’m skeptical of anyone who claims to have a clean framework for this. I think there are good reasons we changed the default. I also think we’re bringing a lot of the same sloppy assumptions with us.

My view is that we probably underinvested in technical upskilling before AI, and we may be overcorrecting now. AI has changed who can benefit and what it costs to help them. That gives us a reason to reconsider the investment, but it doesn’t make company-wide adoption a goal we can stop thinking about.

We drew a pretty weird line.

Think about what we expected from people in the 2010s. Excel and PowerPoint were normal. Depending on your role, maybe Tableau or Looker. A designer could spend years getting good at Figma and nobody would find that strange.

But SQL was “nice to have.” Python meant you were becoming a different kind of person.

I’m describing the norm I remember across job descriptions and teams, and I know there were exceptions. Airbnb, for example, built Data University to teach employees across roles how to work with data, including SQL. They also gave people shared tools and access to the data. The training had somewhere to go.

Still, why was a coding language so much scarier than Figma? Learning the tool was acceptable up to some threshold, and then we started talking about whether someone was “technical.”

There were real reasons for that. Writing a useful query requires understanding the data. A script someone runs every day can become something the company depends on, and someone has to maintain it. If you use it twice a year, the learning time might never pay back.

I don’t think the old “technical” versus “non-technical” gap was ever as large as we made it seem. I suspect we stopped too early with a lot of people. Someone who knew the business inside out might have gotten a ton of value from a little SQL or Python, without needing to become a software engineer. We often treated those as much closer to the same thing than they were.

AI as the great bundler.

You used to be a data analyst who spent your time in Postgres or Looker. Or a designer who spent your time in Figma. Your role and your tools were pretty tightly connected.

You can already see some of this in how people use Claude or ChatGPT with connectors instead of opening individual SaaS apps. Now you can work through a question, write a query, mock up a page, and build a first version of it in the same AI workspace. You still need the underlying systems, and you may still go back into those specialist tools. But you can attempt a much bigger part of the work yourself.

I think of AI as the great bundler here. You can pull activities out of several different roles and put them together around something you want to get done. A marketer who understands the customer might be able to build the little tool they’ve wanted for years, instead of writing a brief and waiting for three other teams.

I expect we’ll see more of this across human capital too. If you’re a builder, and you’ve developed enough domain proficiency to do useful work, why would your scope stop at Design, or Finance, or CX? You might notice that the customer problem you’re working on requires a different onboarding flow, a better internal report, and a small change to the product. Being able to attempt more of that yourself changes what your job can include.

I think job titles and scopes are going to evolve rapidly and horizontally. We’ll have to figure out who owns what when someone’s ability to solve a problem extends well beyond the tools and tasks we hired them for.

That doesn’t give them an analyst’s understanding of the data or an engineer’s judgment about what will break. Domain proficiency still matters, and the cost of getting something wrong varies a lot. It does let them get further before they need to ask someone else.

Automation tools already moved us in this direction. AI has made the upfront investment smaller again, while making it harder to predict who will take to it.

Some people see something and want to make it.

The confusing piece is that we haven’t just expanded the old spectrum a bit in one direction. You can’t work your way down the org chart from engineering and expect the next group over to be the next best at this.

You get something more like this hypothetical team:

“Half our engineers clearly derive a ton of leverage here and half seem to not. But our social media intern is fucking crushing it right now, even though our lifecycle marketing team is really struggling with it.”

Skills, intelligence, and education still have a lot to do with it. But I suspect personality and behavioral patterns have more to do with it than we’re used to accounting for. Curiosity. Entrepreneurism. A bias for action. The willingness to spend a few hours figuring something out before deciding you need someone else to do it.

More technical people are probably more likely to be builders. I just don’t think the relationship is as direct as we’ve treated it, and you likely have builders sitting in places you never thought to look.

The gap between “technical” and “non-technical” has shrunk massively. And the distinction I find myself thinking about more is “builders” and “non-builders.” Who sees a problem and thinks, “I bet I can figure out how to make something that solves that”?

I don’t mean everyone should become a founder or spend their weekends making apps. I mean the person on your team who keeps finding things they could improve and trying to do something about them. AI gives that person a lot more room to run, including when they’ve never thought of themselves as technical.

I’m also wary of replacing one overly stark divide with another. Someone can be curious and self-sufficient in one part of their work and have no interest in building software. Someone else might have the interest but no time, access, or permission to try.

And the intern who makes an impressive demo still has to show that it works. The engineer asking annoying questions about reliability might be doing exactly what you need. Enthusiasm is easier to see than judgment.

So I’d treat “builder” as something someone does in a particular situation. I wouldn’t put it on their employee record after watching them use ChatGPT for a week.

A much bigger pool still has limits.

In my head, the rough sketch goes something like this: less than 5% of the workforce building software, mostly engineers. More investment in coding skills might have expanded that pool, but I have a hard time imagining it getting past 10%. Automation tools were opening up something more like 15% to 20%. With AI, I can imagine something closer to 50%.

Those are intuition-level numbers, not workforce estimates or a forecast. I’m also using “building” much more broadly than “employed as a software engineer.” I mean people who can create a useful tool or change how something works as part of their job. The distinction between those two populations is a lot of what I’m trying to get at.

But even if you buy the 50% intuition, 50% is still not 100%. We should be realistic about what we expect the KPIs for AI adoption to look like. Giving the whole company access might make sense. Expecting everyone to build, use the tools equally often, or get the same amount out of them seems like a much stranger goal.

Then we flipped the training default.

It makes sense to offer AI training to a much broader group than we offered coding training to. You can get value from drafting, research, or working through a spreadsheet without building anything. And a short introduction can help someone discover a use for it that neither of you would have predicted.

But “AI adoption” seems to contain everything from “here’s how to use this tool responsibly” to “our marketing team should be building its own agents.” Those are very different asks.

For this kind of technical upskilling, it feels like we’ve gone from “default toggled off” to “default toggled on.” Both postures have reasonable explanations. Both can lead us to spend too little on some people and too much on others.

My hunch is that a lot of companies would have benefited from being more diligent about SQL, HTML, and Python training over the past ten years. I also suspect a lot of the AI training happening today won’t pay off. I don’t have the evidence to tell you how much of either. But I don’t think changing the default has relieved us of the need to ask.

From an ROI perspective, AI feels like a much more reasonable investment than teaching everyone at the company to code. But a lot of the cost of learning to code was upfront. Once you knew how, you could keep using that skill without paying for each bit of code you wrote. You still had infrastructure, maintenance, and other costs, of course.

With AI, the token spend keeps going as you use it. The person experimenting more, or the workflow running more often, can keep adding to the bill. On top of that, you pay for checking the output, fixing things, and keeping them working. If you’re not paying attention, AI adoption can become a runaway train even when the cost of getting started looked tiny.

And if you’re trying to judge the training itself, you need to ask what the person would have done with access to the tool anyway. All the value they get from AI doesn’t automatically belong in the training provider’s ROI slide.

I’d give more people a chance, without demanding the same result.

This is part of how I think about AI adoption at Won. I’d encourage people to try AI on their actual work. Offer training. Give them access and some room to experiment. Reward the people who find useful ways to do things, especially when they’re coming from somewhere you wouldn’t have thought to look.

Then pay attention to what happens. Did the work get better? Did something get done that previously wasn’t getting done? Did the person save an hour, or spend that hour checking and fixing the result? If they’re struggling, is another class going to help, or are they missing access to the data they need?

Some people don’t like it, don’t want to use it, or don’t get much out of it. Depending on the role and the stakes, that can be okay. If someone does good work with different tools, I don’t need them to perform enthusiasm for AI. If their job now requires something they can’t do, we should be clear about the requirement and give them a reasonable chance to learn.

Excel is a useful comparison. Some people just get it. Some people become great at it because their work gives them a reason to. We don’t expect everyone to become the person who builds the complicated financial model. With AI, we’re still figuring out which capabilities belong in that category and which are closer to being able to open a spreadsheet.

I want us to be much less confident about who gets to be technical, and much more specific about what we’re asking people to learn. I’d rather give someone time to try building something useful, see where they get stuck, and spend the next training dollar helping them through that.