Start With the Schlep: How We Got Nontechnical Teams Building With AI

“It will be of little avail to the people that the laws are made by men of their own choice if the laws be so voluminous that they cannot be read, or so incoherent that they cannot be understood.”

—James Madison

Now, what relevance does that quote have to deploying AI in your organization?

About as much as 90% of the think pieces on LinkedIn, which is to say, very little.

It’s no one’s fault, particularly. This is brand-new technology that we’re all scrambling to understand: the next printing press, an abstraction of knowledge work in a way we’ve never seen before.

It’s powerful and terrifying, useful and useless, all in the same breath. Anyone claiming to be an expert on the topic is lying for one simple reason: it hasn’t been around long enough for anyone to become one. At least not LLMs as we know them today, and certainly not the agentic technology that we can now all have at our fingertips for a mere $20 a month.

The only way any of us will get a handle on how to actually extract value from this technology is by doing, trying, and failing.

I’ve had the privilege of doing a lot of all three, especially recently, as we rolled out a plan to deploy these tools more actively across our organization rather than limiting them to our technical team.

Agentic AI is an incredible tool for engineers, certainly, but it is also an incredible tool for everyone. If you’re limiting your most powerful tools to only your most technical users, you are cutting yourself off at the knees.

I’ve been given the latitude to fall on my face and learn as I go quite a bit over the past year, and my hope is that, by sharing this piece, I can help whoever reads it feel a little more comfortable using AI tools in ways that actually drive results. I hope I can help someone decide where to start and how to involve their entire team, including those who may be fearful of the technology.

Whether you’re a CTO, an accountant, a developer, a project manager, or anything in between, I hope this brings value to you.

Where to Start

I had the pleasure of attending Georgia Tech’s AI for Business course.

It was a unique room in a lot of ways, but one of the most noteworthy things to me was the mix of people who took the course. Their job titles, comfort with technology, familiarity with AI, and professional backgrounds were all over the map.

The common thread was curiosity, and the feeling of being behind.

Professor Keith McGreggor, who runs the course, said plenty of poignant things over those few days, but a couple of them have particular relevance to this topic.

The first was that, given how quickly this technology is moving, how rapidly its doubling rate has grown, and how frequently new models are being released, the most educated person in the world could make the perfect decision about which tools to adopt one week, only for it to become the wrong decision by the end of the next.

I think this is important to remember.

We’re all behind. This technology is moving too quickly for anyone to ever be fully caught up. Stay open-minded, stay nimble, and stay dynamic, and you’ll be doing better than 99% of the world.

The second lesson was simple:

If you want to know where to start when deploying AI, begin with the schlep.

He went on to define schlep as the part of someone’s job they absolutely hate, the tasks that drag them down.

There are a few reasons why this simple strategy is so effective.

First, it immediately creates buy-in.

Everyone has a piece of their job they despise. Even the biggest AI critics, doubters, and skeptics in the world would sing your praises if you could make the most tedious part of their jobs handle itself.

The second reason I’ve found this approach so effective is that it almost guarantees there will be real value.

No matter the size of the business problem, you are still solving a business problem while improving morale at the same time. If you did nothing else but go around using AI to cure all the schlep in your company, you would still have revolutionized your organization.

The Why

As your ambitions grow and your sights aim higher, however, I believe another framework becomes more useful.

Mik Kersten’s Output to Outcome is a brilliant book that serves as a blueprint for how we should all be running our organizations in this world of agentic AI.

I couldn’t begin to summarize the entire work here, but one of the ideas I latched onto, and have built our initiatives around, is the importance of focusing on the outcome.

This also ties into Jon McNeill’s The Algorithm and the general concept of first-principles thinking. It is about continuing to unpack a problem until you are genuinely focused on the why.

What are you actually trying to accomplish?

If you only solve schlep, you are still helping, but your impact probably has a ceiling.

If Joe has to pull the same spreadsheet every day and you help him design a workflow that does it automatically, that’s great. But you may simply be helping him produce an output that doesn’t have a real purpose.

It may have one, but it may not.

Thinking about the core outcomes your company is trying to achieve, identifying its main value streams, and then building downward from those outcomes is the most effective way to identify where AI can be useful.

It also has the benefit of identifying where you can improve the company more broadly.

Some of the biggest gains we’ve seen at Rockhaven this past year did not come directly from technology. They came from mapping our processes so we could determine how to leverage technology, and, in the process, identifying steps that never needed to exist in the first place.

So how can we create value and move quickly without simply automating bad processes?

How do we avoid using AI merely to do the same things we were already doing?

What I’m about to propose is not particularly inventive. It is really just a combination of lessons I learned from the sources above, some Agile best practices, and a lot of personal failures.

But it has been effective.

And I believe it is something anyone reading this could begin implementing at their organization tomorrow.

Our Strategy

The strategy we’re using is simple, but I think that simplicity is what has made it effective.

We now have people from across the entire spectrum of technical proficiency creating real tools that not only make their jobs easier, but also move the organization forward in meaningful ways.

We began by having our senior management team work together to identify key outcomes.

These were intentionally broad, sometimes as broad as “Sell More Homes”, but they varied.

Identifying the outcomes required some effort. Often, it was easier to begin with a project idea someone already had, ask what that project was supposed to accomplish, and then work backward from there.

People naturally gravitate toward defining outcomes and projects around their departments. It is important to dig deeper and examine what the work is truly intended to accomplish.

We have to make sure we are not creating arbitrary starting and stopping points simply because those boundaries reflect how the organization is currently structured.

Once we established the outcomes, we began defining the details of the projects.

As I mentioned above, it was crucial to dig into what people were actually trying to accomplish and encourage them to think bigger.

From there, we established what we call an Outcome Team for each project.

In most cases, these teams were cross-departmental. We tried to map out:

• Who the end users would be

• Who currently touches the process

• Who needed to have a voice in the solution

• Who might be able to identify risks or push back on assumptions

• Who possessed knowledge that the rest of the team might lack

Once the teams were established, we selected an Outcome Owner for each one.

The position is largely similar to that of a Scrum master.

Outcome Owners are responsible for making sure their teams meet and for removing blockers. Teams are encouraged to build as much as possible without direct help from a developer. We primarily used Claude Cowork for these projects.

When a team encounters a technical blocker, the Outcome Owner is responsible for bringing it to me or another developer.

When a team needs approval or information from accounting, the Outcome Owner is responsible for helping unblock that issue.

Ideally, the Outcome Owner acts more as a facilitator than a dictator.

The real value comes from the team working together, ideating, challenging assumptions, critiquing interfaces, and pushing back on one another’s ideas.

That value is not limited to the final deliverable of a specific project. It also comes from helping everyone become more comfortable with the tools and training their minds to focus on what is possible.

Outside of that structure, we hold a weekly stand-up involving me and the Outcome Owners. This gives everyone an opportunity to:

• Share how their projects are progressing

• Discuss blockers

• Get feedback from one another

• Agree on which projects to pursue next

• Revisit the intended outcome

• Identify security, deployment, or organizational concerns

I also hold weekly office hours where people can ask questions or simply work in the same space as others to exchange ideas.

This structure is still new for us. It is the product of several earlier attempts that gradually evolved into what we are doing today.

But the results have been, for lack of a better phrase, really freaking cool.

Seeing my CFO design and build a SharePoint app almost entirely by herself, one that could make PTO tracking 30 times easier than how we do it today, was amazing.

Seeing my Director of Purchasing, who had never used Cowork before we instituted this program, construct a lumber-pricing tracker within 24 hours was incredible. The tool eliminates roughly half a day of work for him each time the process is completed.

But the biggest win was seeing other members of the team become inspired and immediately begin working on side projects and solving their own schlep.

People who were fearful, skeptical, or somewhere in between are becoming power users. I firmly believe that transformation is going to change how we operate as a company.

Balancing Autonomy and Structure

Security, deployment, and organizational structure are all still concerns, and we are far from working out all the kinks.

Keeping me involved, setting outcomes and key projects together, and holding recurring meetings have been our ways of balancing individual agency with organizational safety.

The ritual of the weekly meeting gives us an opportunity to circle back to the intended outcome and, hopefully, catch anything particularly harmful or wasteful before it gets off the ground.

It also allows the process itself to remain iterative as we continue learning.

Everyone’s ideal structure will look different, and it should.

I know others who lean further into gamification, using sprints and points with their nontechnical teams, and they have seen great results.

However, I believe the core concepts we are trying to employ are universal:

1. Always start with the outcome, and always return to the outcome.

2. Create avenues for constant iteration, feedback, and assessment.

3. Use cross-departmental teams and encourage cross-functional discussion and brainstorming.

4. Do not be afraid to fail.

That final principle is perhaps the most important.

Assuming you’ve incorporated enough structure, check-ins, and approvals that they can’t expose anything mission critical, the worst realistic outcome is that a team cannot figure out how to complete a project, no matter how hard its members try.

But even then, they approach the next project with a better understanding of their own limits. They may also emerge with a thoroughly developed vision and a detailed set of specifications for a future solution that can be handed to a technical team.

We’re all going to fail a lot in the days ahead.

And we’re going to find a tremendous amount of value in those failures.

Knowledge Governs Ignorance

In the interest of symmetry, I wanted to end with a James Madison quote that I believe actually does hold some relevance here:

“Knowledge will forever govern ignorance; and a people who mean to be their own governors must arm themselves with the power which knowledge gives.”

—James Madison

Knowledge has never been more readily accessible.

We have the unique opportunity to empower not only ourselves, but our entire teams, to reach out and take hold of it.

And to unlock all the power that comes with it.