[Blog] The 3 modes of startup work help corporate innovators too

TL; DR

This is the first installment in an occasional blogpost series that reflects on my experiences as a corporate innovator now working at a startup.

In this post, I point out how my startup work has required me to switch among more modes of work (at least more and more quickly so) than my corporate work has done.

I have learned that corporate innovators also benefit from understanding all three modes of work and–at minimum–laying groundwork for all three, even if they themselves don't use them all themselves.

Corporate innovation tends to happen in "project" mode

In my corporate innovation work, I find projects to be the near-exclusive mode of work. By that I mean that work has defined objectives, starts, and ends. Even when we taste live solutions with real users, it's always clear that this is all temporary.

For example, one time, a team and I tested a digital solution for use in physical retail stores. We set up the solution, studied how users interacted with it, and learned whether it adds any value for users. We then iterated on the solution and repeated our in-store testing 5 times.

But, as was clear from the get-go, that was it. We knew that if our solution were to be successful, we would hand it off to a different team that would work out the kinks and get the solution ready for daily use under normal operational conditions.

Another time, a team and I tested a consumer product via a limited-time in-market test. When people ordered the product via online retail, our team processed the order and shipped out the solution to the user. But again, there was an end date, at which we knew we'd evaluate the success of the test. If it were to turn out attractive, another team would carry the work forward. None of our operations were stable, let alone scalable. There was no point.

Is that the only way to be? No.

For example, Uber has talked publicly about how their New Verticals Team operates new businesses until the business reaches 5% of company revenue. That kind of scale can't happen without solid operations and processes in place.

In a variation on that theme, at a large American consumer-facing company, innovation teams would start work as projects. But if the effort turned out to be successful, the project team would become the founding business team and carry the work forward, either as a division of the parent company or as a startup that would be spun out.

But considering all the innovation teams I have ever encountered, those two teams are in a small minority. Few corporate innovation teams expect to run functional businesses. Much more commonly, teams involvement in topics starts and stops. It's work in "project mode."

Startup efforts fluctuate between three modes of work

Now I also participate in a young startup and own ongoing work myself.

Three startup work modes

(By the way, since tone is hard to convey in writing: All of these have been efforts I enjoyed, each in its own way.

I complete projects that start and end. For example, there was creating our first website.

It wasn't simply "hey, we need a website. Could you design and create it from scratch?" It was also, "hey, we probably also need company colors and our first verbal and visual style guide ... and all the photos and graphics for the site." So it was somewhat fractal-like. But it was still a stand-alone project with just about no follow-on work to-date (other than some annoying details where emails from our URL and contact form were treated as spam 🤦‍♂️).

I also create repeatable, ongoing processes. For example, inventory management and bookkeeping have been prominent processes (well, groups of processes) that I've gotten to stand up.

They took one-off efforts before. But once done, there will be repeatable steps that reliably get the job done and might even be documented.

It was a crazy experience too. When I worked in retail, I had massively-heavy-duty inventory systems pre-configured and ready to go at my disposal. Here, I had nothing to start. So first I had to research what inventory management and accounting software might be lightweight enough for the needs of a young startup.

It was downright comical how some ERP systems and specialized apps that advertise as being "easy," "affordable," and "fast to implement" are ... none of these.

In the end, I am still considering one system and working toward a future where we can prioritize implementing it. But for the moment, I created the simple cores of finance, accounting, and inventory management systems right in Excel, relying on prior experience.

Upside? I get to use my "systems" day-to-day and find out what we truly need before trying to implement it in a formal system.

And finally, I also perfect things. For example, optimizing app load times and reducing component costs for our hardware components are activities that you might find in very similar ways at mature companies.

The load times become discussions between Engineering, UX/ UI, and me in Operations, with our CEO as balancer of different priorities.

Meanwhile, optimizing bills of materials is something on which I variously work directly with Product, Sales, and/ or Engineering, depending. At one point, for example, a prospective client really liked our solution. But they found it much too expensive for their needs. We went back to the drawing board and came up with a way to make costs tumble while keeping feature tradeoffs acceptable for the client. Another time, we found that something as boring as switching suppliers could benefit costs significantly without sacrificing quality.

(By the way, does all this sound like "work?" It should! But it also can be fun at the same time. More on this later on.)

The herky-jerky cadence of switching among work modes

I wish I could tell you what mode I might use when or for how long. But I totally can't:

The cadence of what I do when is not linear. I'm never "done" with one mode, nor "graduate" to the next.

It's also not iterative, the way we often think of it, in terms of somewhat clean and predictable cycles, a la "test, learn, iterate."

Instead, it flip-flops suddenly, and often super-fast:

One minute I may be in process creation mode, barely able to make work repeatable with metaphorical duct tape, the next I'm working on perfecting something, the way I might in a mature company. And then it all stops, and I have to do something that's totally one-off. Even things that have gotten fairly standardized might suddenly require a total ripping apart and re-building, catapulting me back to project mode (at worst) or process creation (at best).

Advice for friends

How this experience can feel

It's hard to overstate just how stark the difference is of going from a big organization to a startup. Relating to this topic:

NOTHING AT STARTUPS EXISTS.

Whatever you want to have or use is something you also first have to create. And while you focus on creating that, there are a hundred other things that are also urgent and important but that you just can't do at the same time.

Talking with friends who have worked their entire careers at big companies, some do get this. But others have had a very difficult time even imagining just - how - basic one's starting point is in a young startup.

I don't blame them. It's like being a "fish in water." One may not necessarily notice the medium in which one swims. These are also smart people. Once I do point out just how rudimentary things are at a startup, they get it after a few attempts of creating ever simpler standards for what already exists. But it's the kind of thing that's only obvious after one knows.

What it means for corporate innovators

Of course, not every corporate innovation team ever plans to run the businesses themselves that its members dream up.

So the point is not for everyone to practice switching among three modes of work.

But what does matter is building empathy for those people who will eventually take over your work and try to turn it into a active division or other part of your organization.

We may think we already have such empathy. But my experience has taught me that we can easily have big blindspots despite all our training in empathy and in not confusing your own perspective with that of users.

Or as a friend once told me (paraphrased a bit):

"You know what the term 'startup' is short for? 'Startup company.'

Eventually, this must be a company. And so you have to create everything that you know a company eventually needs, not just the cool bits."

And doing that takes projects, process creation, and perfecting of outputs.

T.I.S.C.

AI notice

I created one or more visuals included in this post with the help of AI.