Leadership in the Age of AI

For most of the history of enterprise technology, having an idea and being able to build it were two very different things.

An employee might understand exactly why a process was frustrating, what customers needed, or which internal tool would make their team more effective. But turning that idea into working software usually meant finding budget, writing requirements, securing technical resources, and waiting for someone else to build it.

AI is beginning to remove that separation.

Employees who have never considered themselves developers can increasingly create working applications, agents, dashboards, automations, and internal tools by describing what they want and iterating on the result. The person closest to the problem can increasingly participate in building the solution.

Some companies are already treating this as an organizational capability rather than an interesting experiment.

Replit says Zillow has roughly 600 employee seats and that its employees created more than 7,000 applications over the course of a year. Rokt took the idea further through a company-wide build event: more than 700 employees, including technical and nontechnical teams, participated in a 24-hour hackathon and produced 135 working internal applications spanning operations, finance, legal, engineering, and go-to-market functions.

Firecrown Media followed a similar path. After initially using Replit to solve an internal budget-management problem, the company ran a broader hackathon in which nontechnical employees built tools for problems they understood themselves. Marketing teams built ways to consolidate data, other employees created proposal tools, and one employee-built image system progressed toward a company-wide solution.

The same behavior is appearing around tools that were originally perceived as being for developers.

Anthropic has documented its own nontechnical teams using Claude Code. Its growth marketing function used it to create automated marketing workflows, while members of its legal team built internal tools and prototypes without traditional development resources. At Rakuten, the company explicitly invited non-engineers to use Claude Code, providing context and coding guidelines so they could contribute to technical projects without directly writing the underlying code.

That matters because the leadership question is quickly changing.

It is no longer simply, “How do we get our developers to use AI?”

It is becoming, “What happens when far more of the organization can build?”

Giving employees access to these tools is only the first step. A license by itself does not create a building culture, and telling people to “go experiment” is unlikely to produce the best result. Most employees have spent their careers being consumers of software, not designers of it. They may understand their problem extremely well while having little experience defining requirements, reducing an idea to a useful first version, testing whether it works, or recognizing when something they have built is becoming risky.

That suggests a different kind of capability building.

Instead of teaching everyone to code, organizations can teach people how to build: how to identify a worthwhile problem, scope it tightly, turn it into a first working version, test it with users, understand where AI-generated software can fail, and recognize when an experiment needs technical, security, or governance support.

The environment matters too. Employees need somewhere safe to experiment, with clear boundaries around the data they can access, the systems they can connect to, and what can or cannot move into production. They need examples of good builds, access to people who can help when they get stuck, and a clear path for what happens when something they created becomes genuinely useful.

One practical model is to combine access with structured build programs.

Start with real problems submitted by employees rather than generic exercises. Give cross-functional teams a contained environment and the tools to build. Teach enough product thinking, prototyping, AI literacy, and responsible use for them to make sensible decisions. Let them produce something working. Then bring technology, security, or governance teams in when the strongest ideas are ready to progress.

This is also the direction our own training is moving in.

We design hands-on building programs where participants do not simply learn what AI tools can do. They use them to solve real business problems, build agents and working prototypes, test ideas with users, and develop the judgment needed to understand what should remain an experiment and what is ready to move forward.

For organizations that want to build this capability more broadly, we also help structure the environment around it: identifying the right tools, creating practical guardrails, designing build challenges or innovation sprints, and training employees to move from problem identification to prototype and pilot.

That can take the form of focused workshops, function-specific build sessions, company-wide innovation programs, or train-the-trainer models that help organizations develop internal capability rather than relying indefinitely on external support.

The output is not only a collection of prototypes.

It is a way of discovering problems that central innovation teams may never have seen, identifying employees with an instinct for building, and creating a pipeline of ideas that have already moved beyond a PowerPoint presentation.

For organizations looking to go further, those programs can feed directly into corporate innovation and intrapreneurship efforts: identify problems, build quickly, test with real users, select the strongest ideas, and develop them into pilots rather than allowing the energy of a training session or hackathon to disappear the following week.

The opportunity is not to turn every employee into a software engineer.

It is to give far more people the ability to act on what they already know about the business.

When that happens, the constraint begins to move. The organization may no longer be short of people who can build.

The harder question becomes deciding what is worth building, what is safe to scale, and which ideas deserve to become part of the organization itself.