Risto Siilasmaa had built software companies. That’s why the numbers in front of him didn’t add up.
He joined Nokia’s board in 2008, the year after the iPhone was released. Nokia was still the largest phone maker on earth, and its Symbian operating system still ran more smartphones than anything Apple or Google had shipped. Risto was the only board member with real software chops. He had founded F-Secure—a cybersecurity company in Helsinki—and his own engineers had been writing antivirus software.
What confused him was Nokia’s spending. Symbian had a budget of hundreds of millions of dollars. It was hiring programmers as fast as it could find them. Everyone understood that the iPhone was a threat. The urgency was palpable. The talent was hired. The budget was approved. Still, the software always came late. And when it arrived, it was buggy.
Then someone confided to Risto how long it took to compile the code: 48 hours.
Compiling is where the code that a programmer writes gets turned into something the phone can actually run. It’s how you find out whether what you just wrote works. At Nokia, a programmer made a change, started the compile, and waited two days to see the result.
“It was the equivalent of a movie director on a set having to wait 48 hours to view the latest take before deciding whether it needed to be redone,” Risto later wrote in his book, Transforming NOKIA. “Even a 24-hour compilation time was appalling. Waiting 48 hours to test how well a program works is an eternity.”
It got worse. The 48 hours were for one programmer’s piece. The full build, which required gathering code from every team and turning it into a working version of the operating system, took up to two weeks—two weeks to learn whether a change had worked or whether it would break something.
“This was a recipe for catastrophe,” Risto recalled, “and a catastrophe was exactly what we had staring straight into our eyes.”
At Google, a comparable build would take under 20 minutes. And Google’s engineers were complaining that 20 minutes was too slow.
Now the bill comes by the token
Eighteen years later, the same mistake has returned.
Through 2025, companies put AI in their workers’ hands as fast as they could. Write the code, draft the memo, and clear the ticket. Nvidia’s Jensen Huang egged them on, indicating that a $500,000 engineer who didn’t burn $250,000 a year in tokens would alarm him. The idea for companies was to do more with the people they already had.
Then the token invoices arrived.
At this point, Amazon, Walmart, Uber, Cisco, and Meta had all started to ration token use. Uber ran through its whole AI budget for 2026 by April, and now it caps each employee spend at $1,500/month. “It’s very hard to draw a line between one of those stats and ‘OK, now we’re actually producing like 25 per cent more useful consumer features,’” lamented the Uber COO.
The spending was clear. Less clear was the effect on business performance.
If you enjoyed this article so far, subscribe now. It’s free and takes just seconds to sign up.
You’ll join 18,000+ other ambitious executives receiving research-backed insights delivered straight to their inboxes. Let’s keep you one inch ahead.
I personally watched an engineering team at one of the world’s largest tech companies, not a hyperscaler but close enough. It gave an AI coding assistant to the whole engineering group and tracked it for a month. Almost everyone took it up. The number of changes that each engineer shipped per day rose about 20%. Quality held. Things got a lot better, by their own department’s measures.
And yet deployment frequency, how often that finished code actually reached customers, did not improve much. Instead, it remained flat. When I asked why, one of the company’s engineers told me that the bottleneck sat further down the line, in the testing and the checks between a written change and the one that goes live. A faster keyboard at one end could not speed up the other.
A company could buy every token that its engineers asked for, and the product still shipped at the same rate, because the wait is now bottlenecked further downstream.
The prize is a company of one
So far, this has been a warning. Here is the promise, not just a faster typist.
Paul Cheek, who teaches entrepreneurship at MIT, has a name for those who are already living in the promised land: the AI-driven enterprise. They may not be tech giants themselves, nor in the business of selling AI. They can be any operating companies, manufacturers, or banks, but they would use AI in every function of the business, like planning, marketing, sales, finance, hiring, operations—all of it.
He points to Cursor, a coding firm that, by his account, went from zero to $100 million in recurring revenue in about a year, with only a few dozen people. LinkedIn and Airbnb each needed more than 500 employees and the better part of a decade to clear the same bar. Cheek’s forthcoming book puts the thesis in the title: No One Works Here. What it describes is a company where the work no longer needs an army to do it.
It also reminds me of a book by a designer named Paul Jarvis. In 2019, he wrote Company of One, defining it as “simply a business that questions growth,” meaning that these are companies using systems and automation to make more money without mindlessly adding people. Back then, it read like a manifesto for someone who hated meetings. But now, AI has turned it into a way to run a real company.
How? The unit of work is shrinking. What used to be a project with stakeholder management is now a task.
You can feel it on your own laptop. Let’s say there’s a 30-minute Zoom call that I want to turn into a short video for LinkedIn. It used to mean hiring an editor, briefing them, and waiting two weeks for the cut. Now I drop the file into one app, Submagic, and get five finished, captioned videos back in about 20 minutes.
The job never left my desk for a vendor or a colleague. Each step that used to wait on someone else shrank into a task that I get to finish on the spot. And the feedback is instant. I see what works and what doesn’t right away. No more two-day wait for someone else to compile it.
Paul Cheek can do the same thing to a whole company, live, in about 30 minutes as a demo. He points an AI agent at Reddit to read what real marketers complain about, and he picks one real problem. He turns it into a business plan. He has one tool that builds a landing page good enough to put in front of shoppers.
He then has another tool that he can use to build a five-year financial model by typing what he wants instead of agonizing over a spreadsheet for days. He ends with an investor pitch deck. “It used to take my students months,” he says. He has a warning, however. “What comes out is a rough first draft, a version one that you still have to take into the real world and test.”
The agents are just fast and endless. They are average workhorses, and not yet brilliant.
But remember: average-and-now often beats brilliant-and-later. Just ask Nokia.
So why do big companies feel so slow? Usually, it’s not because the people are lazy. We saw already, it’s that everyone all waiting on someone else. And the wait never ends because the parts of a company run on different clocks:
Finance closes the books four times a year.
R&D plans its bets five years out.
Customer support hears from customers every day.
The online store learns something new every second.
Those clocks never line up. But they aren’t meant to. The website can detect this morning that customers suddenly want a cheaper bundle. Sales turns it into a proposal in a week. However, finance can’t approve it. Because that request won’t be discussed until the next quarter, weeks away, when the management team sits down together.
That kind of time gap hobbles every big company.
The way some would pave their own way
I can’t tell you who will be the first one to do it. But I know how they will. They’ll break up the existing pathway and never bolt on AI just to make each silo go faster without connection.
How do I know? Age-old wisdom tracing all the way back.
In 1990, Michael Hammer named it first in the Harvard Business Review: “Don’t Automate, Obliterate.”
His complaint in the 80s was that companies purchased computers to accelerate work that should never have existed. They were paving the cow paths and pouring asphalt over a crooked trail. His example was Ford.
Ford’s bill-paying department employed more than 500 people, and the plan was to automate the invoices and trim it by about one fifth. Then someone looked at Mazda, which Ford partly owned, and found that it performed the same job with five people!
That was when Ford finally stopped trying to speed up the old process. As the old rule says, “Pay when the invoice arrives.” However, Ford would delete them. The new rule is, “Pay when the goods arrive” and tell the suppliers to stop sending invoices at all.
The work was reduced to almost nothing. The department shrank by 75%, far past the 20% that the automation plan had promised.
Don’t automate complexity.
That’s the whole point for any company holding an AI budget right now. Bolt an agent onto a long, broken, hidden process, and you don’t escape the bottleneck. Worse still, the agent works faster and explains itself less, so when mistakes finally do come out, they are horrible.
What Risto did next
By 2012, two profit warnings were out and a full-year net loss of about €3 billion. The board would finally be data driven, which meant that it finally had to discuss the ugly scenarios, “even a possibility of a bankruptcy.” As one of the board members, Risto finally also had the visibility to see why Symbian could not be fixed, because the flaw was just too deep. It had been built in the 1990s for handsets with only kilobytes of memory. Its thrifty code was written so that it could squeeze into that tiny space. Then the iPhone shipped with 128 megabytes and a clean modern core, and that abundance turned Nokia’s masterpiece of thrift into irrelevance.
So Risto did the Ford thing. Now promoted to chairman, and for eight months the interim CEO as well, he stopped trying to save the phone. For a long time, the optimist in him kept winning the argument. Surely handsets could still be turned around. Surely the company that had put a phone in more hands than anyone else had one comeback left. “I still believed…The optimist side was still winning,” he admits. Then the data kept coming, each month worse than the one before, until the paranoid half of him finally won. “As more negative data kept coming in…we had to divest.”
He sold the phone business to Microsoft, bought out Siemens from the networks venture that both companies had nearly given up on, then bought Alcatel-Lucent and rebuilt Nokia around it. In a little over three years, the company’s market value as a pure network provider went from roughly $5 billion to almost $40 billion. “We essentially transformed the whole company,” he says, “by changing out all the atoms.” Nokia Network is still standing today.
In a way, Risto didn’t speed up Symbian. He obliterated the need for it.
Where to start, if not by running faster
So how do you begin? How can we stop paving the cow path? Here is the order that the people who have actually removed complexity tend to follow:
Follow one job from end to end, and time the wait. Pick a single unit of work—one order, one claim, one new feature—and walk it from the first request to the finished result in the customer’s hands.
DBS of Singapore is legendary for this. It treats the customer journey as the only anchor that matters.
Beside each step, write two numbers:
How long the work takes, and
How long it sits waiting for the next person.
That map is the truth about your company.
Find the one place that sets the pace. On that map, find the one step, or person, that everything else waits on.
This is why the team that wrote 20% more code with AI still shipped at the same speed.
Delete the rule behind the bottleneck. Ask why the bottleneck exists at all. Find the rule that makes it necessary and see whether you can remove it. Delegate, automate, train a human backup, or eliminate.
The whole DevOps movement taught us that.
Rebuild in small, reversible pieces. Never relaunch the whole thing in one shot. Ship in small steps that you can undo. Test each change in a copy of the real system before it affects real customers.
SONOS, a maker of wireless speakers, learned it the hard way. A big-bang launch cost the CEO his job.
The budget was never Nokia’s problem, and the token budget is not your answer now. Speed at one desk or one silo is not speed through a company.
How long are your fastest people forced to wait?
It‘s important not to mix up everything. A software workflow is not a business workflow and both are not governance workflows. Not everything needs the same speed. And not every tech or business workflow can be treated the same. It’s a difference if you build something new, if you integrate something, if you process ad hoc tasks or if you maintain something. You need a meaningful cadence for workflows that are connected.
Regarding shipping software: long before AI there was a concept called DevOps. It‘s worth to research that, because how it was implemented in some companies misses the concept entirely. It was long before AI possible to ship to production the same day you developed the code. With a proper DevOps Setup.
Regarding business workflows: the root cause for problems lies ALWAYS in the set up of the teams. The right mix of roles and accountability solves 80% of all problems.
Governance can be slowlier. The root cause is that topics are treated as governance topics when they are actually daily business. Root cause is wrong setup of roles and accountability.
The big art is to set up several teams and leadership levels in a way that it all runs smoothly.
This is what I do for a living, besides other topics.
It starts with the mindset and it is a never ending work.
The goal is to become a learning organization with a cadence of learning that is not rushed and is sustainable.
Very insightful. Reminds of how Elon Musks thinks and operates.