Skip to main content

Kickstarting Internal Projects

"Kickstarter isn’t a store — it’s a new way for creators and audiences to work together to make things." ~ Perry Chen, Yancy Strickler, and Charles Yadler - Via Kickstarter.com's blog

What the hell is an "Intrapreneur"? ~ Me. About 10 seconds before having my mind blown reading this article on fastcoexist.com

I'll just say it. I want to build a Kickstarter platform inside my company so I can work from within to change the way things get done. How about I explain why...

Last year around this time it was announced that my beloved little startup would merge into a large, multi-national conglomerate. Now those of you who have made that transition know that it comes with some benefits (stock buyout, larger resource pool, potential for job security). There are also typically some changes to how you do things. At a small startup, you typically get as much responsibility as you'd like based on willingness to drive development on products and tools that could enhance the value of the business. Small gains have big impacts in a small company. When your company posts $13.6 billion in profit globally those small gains are harder to make quickly and the impacts just aren't as big if you use the strategies that worked at your startup. This is my current experience, anyway.

One of the most disruptive and democratizing forces in entertainment and technology innovation of recent years is Kickstarter. The concept is simple: hit up a lot of people for a little money and launch your dream project on the many shoulders of your fans. This cuts out the need to pitch a huge value gain to wealthy individuals and replaces it with broad appeal to many small investors. Economies of scale can work in amazing ways. At a small startup, the exhilaration of carrying new ideas on your own shoulders is seductive and it can make it seem like the old adage is true, "if you want something done right, do it yourself." At a large, multi-national, that same exhilaration can come from a new source: your colleagues.

See, there is a huge problem with momentum at large companies. They can be slow to change and it can take more than any single contributor's store of energy to affect a shift in direction. So why fight it? Why hang on to the DIY attitude and do your Sisyphus impression? Learn to delegate. Try your own internal Kickstarter campaign.

Here's what I mean...

Suppose you are in a large, inertial organization, and from within it can feel like innovation is stifled because there are so many people enforcing the status quo just to make status of any kind manageable. For every VP ideologue who's thwarted you, there are dozens or maybe hundreds (or maybe thousands) of others sharing that same experience but who in small ways have still managed to get their work done in spite of them. In the case of my company, one of the biggest hurdles to overcome whenever you want to do something that consumes resources is provide a business justification on the manager's terms for your request. In principle this is not a bad thing. In practice "because it will make me happy and more productive" actually isn't a solid enough answer. You need data. You need risk analysis. You need leverage. The bigger the ask, the more of a case you need to build.

So how does Kickstarter come in? Well let's talk about the nature of Angel Investment in general. It is almost a moral choice to be an Angel Investor. You don't get into it because it always makes perfect financial sense. You get into it because you want to fund good ideas you believe in that need extraordinary support to get off the ground. Kickstarter democratized the process by reducing the individual burden and used economies of scale in order to drive to those extraordinary thresholds. Even now a friend of mine got 3 times his goal on Kickstarter to make silly (read: AWESOME) stories about a T-Rex fighting for the Allies in WWII. As incredible an idea that may be, it isn't the kind of thing we're seeing in movie theaters so pitching to a major studio would have been difficult. Pitching to enough people to get the job done however was easy, so easy in fact he tripled his goal. He's not alone. Many projects when met by the potential consumer make an easy sale even in a system that is explicitly not a store.

The lesson here is that democratizing your pitch benefits you by spreading the risk, lowering the bar to contribute, and getting the idea in front of its fans directly with more long-term ownership remaining in your hands. By making the value proposition to people who by position or contribution stand more to gain than to lose, it is easier to get them on board and take advantage of bandwidth in resource overheads be it labor time, material, or even flat out cash. You can get more done to by extending the Kickstarter model into how Open Source Software is curated. Using commitments for project contribution as a currency (still risky but better than having no money AND nobody to work with), is equally valid in this application. Here you incur a higher project management overhead cost but by using scrum techniques, you can define discrete components of work contributing to the overall project goal and distribute that work accordingly.

Here are some sample steps to apply the Kickstarter model to coping with inertial resistance within large organizations:

  1. Design your pitch. Keep the premise simple and achievable and make sure the audience who will contribute to it is the audience you pitch to; given the resources you're trying to leverage, this could include a wide variety of disciplines
  2. Stratify your goals. Make a progressively increasing value ladder that builds on advancing project scope so that as additional people get on board, you can scale well with them, preferably in a compounding fashion
  3. Set a minimum requirement to get started and do so with a commitment to meet the contributions with the same expectation of completion no matter how far up the ladder you get (i.e. don't overextend either).
  4. Set deadlines and have a plan for how to meet them. 
  5. Deliver early and often. Use your project stratification as a guideline and make your deliveries reinforce the reliability and desirability of this system.


What's the catch? Just like on Kickstarter, until the singularity comes and Maker Bots become sentient, this stuff's not going to make itself; that includes the framework you use to build your internal entrepreneurial engine. The biggest catch now is building a platform which can curate ideas in a discoverable way just as well as Kickstarter does. Only this time we use it for projects in-house. We free up small amounts of discretionary funding and developer time. We focus on the studio model first and then grow wider as the model succeeds or try something new as the model fails. The point is, I may just be a number but I'm not the only one. For my company, there are 193,000 employees worldwide who were hired because they were detail-oriented, hard-working, client-focused, and all that other good stuff anyone would like to brag about to shareholders. The fact is, that means there are probably 192,285 people who are frustrated by how hard it can be to get a good idea off the ground. Wanna guess what happens to those ideas when 192,285 people suddenly realize the inertia they've been fighting is only their own?

Comments

Popular posts from this blog

UiAutomator and Watchers: Adding Async Robustness to UI Automation

"I'm looking over your shoulder... only because I've got your back." ~ Stephen Colbert After my recent UiAutomator review a user brought up an important question about the use of UiWatcher. The watchers serve as async guardians of the test flow, making sure the odd dialog window doesn't completely frustrate your tests. Having a tool that automatically watches your back when you're focused on the functional flow of your tests is awesome. 100% pure awesomesauce. Since the API documentation on watchers is scant and the UI Testing tutorial on the Android dev guide doesn't cover their use in depth, I figured I should add a post here that goes over a simple scenario demonstrating how to use this fundamentally important UI automation tool. In my example code below, I'm using uiautomator to launch the API Demo app (meaning run this against an Emulator built in API level 17 - I used the Galaxy Nexus image included in the latest ADT and platform tools). ...

UiAutomator.jar: What happened when Android's JUnit and MonkeyRunner got drunk and hooked up

"Drunkenness does not create vice; it merely brings it into view" ~Seneca So Jelly Bean 4.2 landed with much fanfare and tucked in amongst the neat new OS and SDK features (hello, multi-user tablets!) was this little gem for testers: UiAutomator.jar. I have it on good authority that it snuck in amongst the updates in the preview tools and OS updates sometime around 4.1 with r3 of the platform. As a code-monkey of a tester, I was intrigued. One of the best ways Google can support developers struggling with platform fragmentation is to make their OS more testable so I hold high hopes with every release to see effort spent in that area. I have spent a couple days testing out the new UiAutomator API  and the best way I can think of describing it is that Android's JUnit and MonkeyRunner got drunk and had a code baby. Let me explain what I mean before that phrase sinks down into "mental image" territory. JUnit, for all its power and access to every interface, e...

Why Developers Shouldn't Perform Software Testing - A Rebuttal

Take a minute and read the following 2-pager entitled " Guest View: Why developers shouldn’t perform software testing ". Man, I tried to like this article because the author, Martin Mudge, clearly knows that businesses who undervalue quality by trying to eliminate testing through simply shuffling the traditional testing task to developers are making a huge mistake. Unfortunately he begins by making an assertion that testing overburdens a developer which at face value is complete nonsense. If you feel overburdened, it is a timeline issue and that is true no matter WHAT the nature of the tasking is.  So his assertion of “one the most important” contributing factors being overburdening the developers is massively flawed. It gets immediately worse from there because his second point is about time constraints.  Mr Mudge just gets so much wrong. What he really should be shooting down is the idea that testing, as a cost-center not as a task, can be eliminated by having your p...