image credit: Feliciano Guimarães
In my most recent post, I asked if enterprise should think small. But as a close friend said to me, it’s one thing to suggest that enterprise should change; it’s another to lay out a clear path for it.
I won’t pretend I have all the answers (or any really), but I do think that with a little critical thinking, together we can talk about practical, actionable steps that translate some of the advantages of small business/startup culture into enterprise business processes.
Applying Startup Speed and Flexibility
Given that key to rapid innovation is the ability to fail fast and fail cheap (a concept that applies to your career too), perhaps two of the most beneficial elements of startup culture are speed and flexibility.
Because of sheer size, some elements of that speed and flexibility just won’t fit into the enterprise.
And probably for good reason. Imagine an enterprise CEO calling everyone at 3 AM to tell them that s/he’s had a breakthrough and that you’re going to completely change your business model.
Doesn’t work. Especially not after that silly IPO.
But at the same time, in a recent interview for the Ask Summit, Emily Jasper suggested that, when it comes to organizational culture, there’s a a spectrum between what we would typically deem “startup culture” and “enterprise culture.” She went on to articulate that it may be possible for enterprise organizations to emulate pieces of startup culture.
I think a responsible and appropriate way to mirror startup speed and flexibility when it comes to innovation is through targeted and fractal development teams.
Fractal Development
Last fall, Terry Weaver wrote about failing fast and cheaply within the context of a quote from Ravi Sastry: “You’ve got to play to win—not play to decide.” Wever writes,
…If you’re considering something new and non-traditional, go flat out. No reservations, no limitations, take no prisoners. And, at the same time, bound your risk. Determine in advance how much time, how much effort and how much money you’re going to risk before making a “go/no-go” decision. Bet an amount that should be sufficient for success, but not enough to swamp the company if it doesn’t work.
The road to responsible risk management, in my opinion, is to remove the layers of approval that often choke off the life of innovation teams.
Once a team is taksed with developing a product, leadership should give them the tools they need to make decisions, to bend rules–in essence to worry about how their plans will fit within the organizational process later. Forcing innovation teams into approval channels often causes the reservation and limitation Wever warns against.
In terms of structure, it’s my opinion that this team should be a fractal of your organization, made up of as few people as possible.
Successful SaaS provider 37Signals recommends orgs use only three people for version 1.0 of any software development project. The point?
Talented people… thrive on the challenge of working within restraints and using their creativity to solve problems. Your lack of manpower means you’ll be forced to deal with tradeoffs earlier in the process — and that’s alright. It will make you figure out your priorities earlier rather than later. And you’ll be able to communicate without constantly having to worry about leaving people out of the loop.
The same logic, I think, applies to projects in other areas—depending on your organization, it could be the development of a new FMCG, a brand new social network-based customer service program, or even a breakout marketing tactic.
Empower fractal development teams
In the end, no matter what the task is, leaders should let the small, fractal team to sort out all of the details. Let them lock themselves in your conference room over the weekend if they want to. Let them work in the park if the want to. Give them the flexibility to be. To create. In short…
Trust the team.
Sure, leadership should make it clear they expect the team to provide something that will address the task at hand; however, the ultimate success or failure of the project should be secondary. After all, this is about trying new things. Some will fail.
But if version 1.0 fails, the organization is out significantly less time and energy than if they would have subjected the initial development to layers of approval and everyone’s scrutiny.
But if it succeeds, that’s when the project can move into a more formal development stage. More hands will be needed to develop version 2.0 as the organization plugs innovation into their current organizational processes.
Your thoughts?
So does this have legs? Could you see this implemented into enterprise culture? Why/why not?
I’d love to continue the conversation.
-Andrew
Image credit: Jsome1 on Ficker; see original for copyright info
Related Posts
No related posts were found, so here's a consolation prize: A Defense of Grad School.
