TL; DR
Books and thought leaders prioritize working "on" a startup, obsessing about "traction," "PMF," and "Scale."
But if that's all they do, they skips major work. Ignoring the importance of working "in" the business, on topics like book keeping and inventory management, can blow up both startups and corporate innovation efforts.
In more mature scale-ups, the pendulum can swing the other way. Working "in" the business can rise to dominance. That too causes trouble if it's the sole focus.
Innovation work takes a conscious understanding and healthy balance of both.
The difference between working "on" vs. "in" businesses
The concept
My friend Neal Wozniak taught me a most helpful concepts, one of the most thought-provoking that I have encountered in my startup journey.
It just so happens that this idea unlocks a lot of cultural and productivity challenges not just in startups but in corporate innovation too.
He credits it author Michael Gerber and Gerber's book The E-Myth Revisited.
Essentially, one way to classify work is to split it between working "on a business" vs. working "in the business."
Working on the business is what the pundits hold forth about: User research, minimum viable products, assumptions, de-risking, reaching for traction and product market fit on the way to scaling, ahem, innovation strategy, and more.
Working in the business means running the business: Paying invoices, doing the accounting, shipping products, answering customer questions, doing continuing engineering and refactoring work to existing code, and all the other unsung efforts.
There are other terms for this concept. For example, my friend Kyle Girard talks about "work" (loosely mapped to "on" the business) vs. "meta work" ("in" the business). And you may use yet other words.
How this differs between startups and big companies
In stable, scaled companies, working on vs. in the business may represent entirely different jobs or functions.
Strategy teams, for example, only work on the business, while Operations teams generally work in it. Finance and Accounting straddle both types of work. A Strategic Finance group, for example, may work "on" the business, engineering new financing structures for a company, while a Financial Reporting team may ensure accurate, responsible records of what happens "in" the business. The list goes on.
In startups, you might zoom out across time and observe a proportionate shift from teams spending more time "on" the business as they figure out what it should even become to working "in" the business as the startup turns more and more into a regular company that starts to resemble its eventual, grown-up self.
Meanwhile, startup work oscillates quickly between the two types.
Sticking with financial work, for example, one moment, I might worry about bookkeeping or about automating said bookkeeping. The next moment, I am designing funding or debt-to-equity structures for the company, which is much more about shaping the business.
Why all this matters
I see three critical insights for innovators here:
For one thing, many people will have a preference between the two types of work. Working "on" the business is closer to creating something the first time. Working "in" the business is more about optimizing what already exists in crude form.
In the end, we need both. But individual people will gain or drain energy if they must spend their time on the kind of work that doesn't fit them–or, if they are like me–if they don't get to switch back and forth between both types in a helpful cadence.
So leaders must stay mindful of individual preferences and company needs.
The second impact of this concept feels like the bigger one to me: In startups and innovation teams, the work that gets talked about and the work that teams often truly value is that of working "on" the business.
Working "in" the business is treated as out-group work, as "executing the brilliant innovation work that we folks on the in-group created for you poor shlubs."
I myself have been subject to this mindset on at least two occasions, one each in startups and in corporate innovation. In one case, supposed "true" innovators scoffed when "the boys in blue showed up." That would be because a colleague and I both happened to wear blue shirts that day. Clearly we were hopeless squares, it was made obvious, who didn't have the same creativity that the cool kids in skinny jeans could offer. Another time, my work was dismissed as "boilerplate," meaning that the other person was doing important, brilliant things, while everything else was obviously easy and much less valuable.
The funny thing was, I even agreed that some of the work I was doing was dull and routine. But it turned out that that didn't matter. What mattered was that my work, too, was must-do. I sacrificed doing work that I found more interesting, so the startup got done what had to get done.
The question wasn't whether some work was "cooler" than something else. The better question was whether work was "important."
Of course, neither speaker would agree that they were being elitist or dismissive. But of course, they don't get to judge that. Being unaware of one's own arrogance doesn't make it any less so. It just means that one is arrogant due to personal blindspots rather than willfully arrogant.
Less explicit forms of this same two-class society in innovation exists elsewhere too. Just as one example, the term "front-end innovation" need not–but in practice does–include certain functions and exclude others. Design and trends & foresights? "Yes, front end." Operations or finance? "Pff, clearly not front end. What are you even talking about, Steffen?"
(I won't get into the problem here. It's just serving as an example. If you fall prey to this problem and honestly want to know why this idea is bunk, contact me.)
To some degree, I understand of course that humans naturally create in-groups and out-groups as part of our nature as communal creatures, who, as part of that social nature, need to define what our community even is. I also understand many of the good things that come from humans' social nature. It's just that here our nature runs overboard with us.
And finally, and most surprisingly to me, a ton of startup work turns out to be work "in" the business or unavoidable "meta work." In other words, we must remember that a "startup" is really a startup company. It's on its way to being a normal company, full of processes, meetings, committees, and, well, normal work.
There's so much talk about the Lean Startup and all the other innovation jargon that it's easy (for me at least) to think that that's all there is. But in reality, working "in" the startup often dominates startup denizens' daily life.
This goes so far that in one established and respect-worthy startup/ scale-up with which I worked, many concepts related to working "on" the startup were unfamiliar to the team. Many of these team members had worked hard to create a viable business. They didn't have spare time to worry about cutesy nerd jargon and concepts. They were busy creating something that mattered in the real world.
At first, this surprised me. But then I realized that smart people working for a startup can easily learn Design Thinking, Product-led Growth, Sprints, and all the rest. The things I had treasured so far actually were relatively easy. Sure, you had to know about them in the first place. But once you did, many of them were obvious. What was harder was the professional expertise related to people's jobs "in" the business. You couldn't learn that stuff from a book and a YouTube channel. You actually had to spend years learning your profession. This is where the company was really being built, at least as much as cool-kid work that focused "on" the business.
Good startup leaders know this and appreciate both work "on" and "in" their business equally. For example, if I didn't make sure that our books were in order, tax authorities would shut us down no matter how cool our software was. And, speaking of software, without marketing, operations, and all the rest, said software would just be a fun intellectual accomplishment on a virtual Github shelf. To be a company, there had to be an actual company bringing the software to life.
Good startup founders understand this even better. There is a saying that "being a startup founder is taking out the trash." If you consider yourself too good to take out the metaphorical trash and merely want to do work that you find cool, you can't be a founder.
Advice for friends
- Equally appreciate all work–both "on" and "in" the business. And know that your actions will speak louder than your words if you actually are elitist and falsely consider one better than the other. People may not call you out. But they will notice and act accordingly. Similarly, ruthlessly eradicate elitism elsewhere among team members that will rot out your culture. Rivalry and competition can be helpful to a degree. Dismissal is not.
- Understand what work is important. Then focus on that. Startups can famously only focus on one major priority at a time. Make yours the one that actually matters, not the one you consider cool (working "on" vs. "in" the business). And then give that work all the care and appreciation you can. If it matters, it matters, no matter how cool.
- Deploy team members to work "on" vs. "in" the business according to their strengths and energy needs. My skills, for example, split across both fields. I need some of each to be happy. You will differ from that, as will your team. Know your people. Deploy them for greatest effect.
Further reading
Gerber, M. E. (1995). The E-Myth Revisited: Why Most Small Businesses Don’t Work and What to Do About It. Harper Business. https://www.michaelegerbercompanies.com/product/the-e-myth-revisited/
AI notice
I created one or more visuals included in this post with the help of AI.
