This article is based on an interview with Matthew Wimberly, CTO and co-founder at Chiri.
Show and tell, not slide decks
Most consulting engagements run on a planning cadence. A team scopes the work, builds a slide deck, and schedules a status update. Weeks pass between visible output.
Matthew Wimberly, Chiri’s CTO and co-founder, describes a different rhythm at Chiri. “Consulting of the past was seventy percent planning and update meetings and staring at slide decks,” he said. “Consulting of the present that we do is quite literally show and tell every week.”
Matthew Wimberly
He calls it the best meeting on his calendar. “It’s the most fun meeting every week for me, because I get to go to clients and say, look at what we did, it’s amazing. I can’t believe that we could do stuff this quick. It’s shocking to me too.”
That weekly cadence comes from a specific team structure. Chiri calls it a pod: a software engineer paired with a business operator, working inside one client’s operations instead of inside a department.
Why the old org chart falls short
Wimberly traces the gap between business and engineering back further than any one project. “The business and the software engineering don’t speak the same language,” he said. He pointed to a common workplace meme: a caveman trying to talk to his users. In the next panel, ordinary employees try to talk to an alien speaking in hieroglyphs. Software engineers, in his telling, get blamed for a threat they named themselves. “We gave it to ourselves,” he said, “which is that we’re a threat because we will automate away your job.”
He called the outcome ironic. Engineers have spent the past decade automating work, he said, yet the work on his own plate has only grown. “Every time I take work off someone’s plate, they find something else to do.” In his account, the real disruption landed first on the back office. Engineers triggered it, by automating their own function before anyone else’s.
That history is why Wimberly does not expect a client’s existing departments to absorb AI work cleanly. IT, HR, and operations are already blending into new combinations inside companies experimenting with this shift. The engineer and operator roles inside a pod are Chiri’s answer to where that blend should start.
Why a software engineer is not a domain expert
Wimberly starts from a plain distinction. A software engineer’s job is to build reliable systems, not to know a client’s business from the inside.
“The software engineers don’t understand the business,” he said. “The software engineers understand how to build things. You’re effectively paying for a carpenter.”
He extends the comparison to a mechanic. “A software engineer is not necessarily a novel inventor at all hours of the day. They are paid to know how the engine in your car runs, because the engine in your car is a one of one. Instead of a factory assembly line from Ford, you have your own race car, and they’re expected to know the ins and outs.”
That framing sets the limit on what an engineer can deliver alone. An engineer can build the system. An engineer cannot know, on day one, where a client’s data breaks. An engineer cannot know which workflow steps are informal. An engineer cannot know which numbers in a report have never been trusted by the people who read them.
Chiri’s early-stage answer is to pair that engineer with a subject matter expert. That expert already knows where a company’s operational problems live. “I recommend, for example, in the early stages with companies, to use a data subject matter expert,” Wimberly said. “The interesting thing with data subject matter experts is that they know where all of the little warts are in your data problems.”
He named the limit of that role too. “That data subject matter expert does not necessarily have the business context, which is why they’ll be paired with business people.”
Pairing an engineer with an operator
The pod pairs two different kinds of expertise on purpose, instead of asking one generalist to cover both.
The engineer builds. The operator carries the context: how the workflow actually runs, what the data has always meant, which fix will hold up in daily use. Neither role substitutes for the other.
Wimberly ties the structure to a shift already underway inside companies. “We’re starting to see the synthesis of IT and HR. We’re starting to see the synthesis of IT and operations. We’re starting to see the synthesis of a few different job functions coming together,” he said. Chiri’s pod model builds that synthesis on purpose, instead of leaving it to chance inside a client’s own org chart.
The change reshapes what the engineer’s day looks like too. Wimberly described the old routine: “Jira board cleanup meetings for two hours, then sitting and staring at code and reading Stack Overflow.” In the pod model, he said, engineers “get to run like the wind and program like their life depends on it.” The business side, in turn, gets Chiri’s inverted consulting model: rapid builds, shown weekly, instead of quarterly plans.
Wimberly described the pods moving through a client organization department by department. “They’ll go department by department, do some intake, start doing some work,” he said. “They’re going to go roving around almost like little mercenaries.” Over time, that roving work gels into something more permanent inside the client’s own operations.
The talent show inside every company
Wimberly’s case for the pod model rests on a second problem: internal AI experimentation, left unstructured, does not scale evenly across a company. He described the search for adopters inside a company as “an internal talent show,” a process of finding the people who take to the work and then spreading what they learn across the rest of the organization.
He described what happens when a company funds broad, self-directed AI adoption without a pod or a clear plan. “If you do that in a self-directed way within the company, that’s exactly what’s gonna happen,” he said, “because there’s not going to necessarily be this top-down approach of determining what is the intake of an ROI-generating activity versus a cost-cutting activity.”
In his experience, the result is a small number of real adopters buried inside a larger group that never gets there. He offered a rough estimate from his own work with clients, not an audited figure. If a company scatters roughly $200,000 in AI experimentation budget across its staff, he estimates it might end up with only about five people out of every hundred who become genuine super-adopters and champions. “Everything else was largely a waste, or very little value was produced out of it,” he said.
Wimberly was direct about the cause. Handing out a budget with no direction, he said, invites people to spend it on low-value novelties. It rarely reaches the real problems that touch the business.
The alternative, in his framing, is concentrating that same spend on people who already have context. That means an engineer and operator paired inside a pod, instead of a hundred employees learning on the job on their own. “The alternative could have been that you could have called in experts like us,” he said. “We work across many different businesses, so we could tell you a similar company, in a similar industry, of a similar size to you, did similar things, or different things.”
Cost, skill, and management
Wimberly named three variables that determine whether an AI investment produces value: cost, skill, and management.
“The cost needs to be managed from the top down, but the expectations of expenditure need to be very transparent,” Wimberly said. A vague mandate to go adopt AI, with no direction attached, leads to scattered, low-value spending.
Skill can be built two ways. A company can train staff internally, in effect paying tuition every month while employees learn on the job. Or a company can bring in outside expertise to compress that ramp. “The time to first value might take a period of months,” Wimberly said, “whereas this you could do in like one, if you come to us.”
Management is the hardest of the three to solve. “You have to have the skill to know what to do, but you also have to have the skill to know how to manage it,” Wimberly said. “And that’s something that can’t necessarily be taught.”
The pod structure addresses all three at once. It puts a trained engineer and an experienced operator together from day one. It compresses the learning curve an internal-only team would otherwise pay for out of pocket. It places management of the work inside a team that has already managed it elsewhere.
The pod as a delivery mechanism
A typical consulting engagement separates planning from building. A statement of work gets signed, a team disappears to build, and a client waits for a milestone review.
The Chiri pod collapses that separation. The engineer and the operator sit inside the client’s actual workflow. Progress gets shown weekly, not quarterly. The unit of delivery is a working result, not a status update.
Wimberly frames the department this new model produces as still forming, inside Chiri and inside the clients it serves. He called it an “AI transformation department, or name pending.” The name is unsettled because the synthesis of engineering and operations behind it is still new across the industry. The pod is Chiri’s working answer to that gap. It is a small, paired unit built to close the distance between building software and running a business.
This lands differently depending on where you sit
A CEO or COO sees a spending problem solved before it starts. Concentrated pods reduce the number of people learning AI on the company’s dime. The odds improve that a six-figure experimentation budget produces more than a handful of real adopters.
A CTO or IT leader sees a staffing model that does not ask one engineer to also cover domain expertise. The pod pairs the engineer’s systems knowledge with an operator’s context, instead of expecting one hire to carry both.
A business unit leader sees a consulting relationship that reports in weekly demonstrations instead of quarterly slide decks. Work is visible as it happens, not reconstructed after the fact.
An individual contributor inside the client company sees a faster path to becoming one of the real adopters Wimberly describes. That path runs alongside someone who already knows how to build the system, not alone.
Where does the highest-value AI work in a company sit today? Concentrated in a paired team with context on both sides, or spread thin across a hundred people learning on their own?