No Pain, No Gain: An analysis of StormCloud

Toyota A3 Report and Entrepreneurship

What sticks out to me about the Toyota A3 approach to problem analysis and resolution, and what makes it a great asset to entrepreneurs and those seeking to start their own venture is the degree to which mentoring and oversight by senior managers plays a role in the problem solving process.

Often times in engineering and technology, there is a belief that experiential learning is the most effective and 'sticky' way for younger, fresher employees to internalize and master the day-to-day nuts and bolts of their chosen vocation; just jump into the work and pick at the problems until you come up with a solution, then, deconstruct the work with a more senior partner to identify areas for improvement or possible mistakes… this is where we get the code review from.

But in the small business/startup world, the stakes are too high and the variables too many to have a 'dive in and swim' approach… you need context, experience, and the ability to see in all directions of you are to make the best possible decisions for your firm.

That's what makes the Toyota approach so interesting when viewed through the lens of entrepreneurship… as the article states, it '…creates an organization full of thinking, learning problem solvers.'  By baking oversight and mentorship into the problem analysis and resolution process, they invite a more thorough transfer of wisdom and experience form the teacher to the student.

This is similar in principle to the goal Entrepreneurship In Residence programs seek to create- pair a senior entrepreneur with a young gun, and immerse them in the world of their ventures. In software development, we call this 'pair programming' and its a great way for junior programmers to get up to speed quickly, learn a new language or framework, or master all the ins and outs of a codebase.

Seven Sources (well, really four)

Peter Drucker defines the seven sources of innovation as:

1. THE UNEXPECTED
2. INCONGRUITIES
3. PROCESS NEEDS
4. INDUSTRY AND MARKET STRUCTURE
5. DEMOGRAPHICS
6. CHANGES IN PERCEPTION
7. NEW KNOWLEDGE

The idea here is that each or any of these sources of cognitive dissonance can server as a catalyst for an innovation. I think before we focus too much on the sources themselves it's worth nothing that there are two kinds of innovations:evolutionary and revolutionary: I want to focus mostly on the latter, as the former to me, while an important part of the innovation economy, tends to be more technical and syntactic by nature, and thus does not lend itself well to an analysis of the art of innovation.

Within the context of Revolutionary innovation, one could make the argument that all seven sources can be in play, but in my mind realistically, revolutionary innovations most often are associated with sources 1, 2, 6, and 7. Let's examine how.

The Unexpected: Broken Buildings: 

When Drucker talks about the unexpected, what he really means could probably better be described as 'The Accidental.' This is not to discount the role serendipity plays in the innovation process; just to say we should call a spade a spade.

To me, the unexpected is in the eye of the consumer, not the manufacturer. Nutrasweet and Post-It Notes may not have been what the engineers who created them set out to create, but that does not by nature make them unexpected. The Unexpected is all about satisfying a need for a consumer in a way they -you guessed it- weren't expecting. The easy example to give here would be the namesake of this blog; chunky spaghetti sauce. But seeing as how I've riffed about that already, let's go for revolutionary and not just evolutionary.

(The iPod is another example, but I believe using Apple as an example is a copout, because everyone in business schools everywhere is using Apple as an example. We can do better.)

Let's try for something more interesting: Broken Buildings (true story: that was the runner-up for the name for this blog.)

Frank Gehry is an Pritzker Prize-winning architect who broke buildings. How does an architect- a vocation whose very nature is to design and construct buildings- break buildings? This Is How. By changing what it meant to build a building, and making people feel things they were not expecting to feel, Gehry broke our previously held conceptions of what a building was, what a building could, or should, be. Critics panned Gehry's work when it was first making waves... now his structures are badges of honor, and command some of the highest commissions in the architecture world.

Incongruities: a tale of Frogs and Flies:

Ever try to swat a fly with anything smaller than a flyswatter? It's unbelievably hard. A flies eyes enable it to see just about 360 degrees, meaning there's no way you can sneak up on it.

Why is it, then, than a frog- an amphibian whose brain is barely a drop in the bucket when compared to a human brain- can snatch a moving fly out of the air with its tongue? 

Because a frogs eyesight is optimized for only seeing things that are moving; the faster something is moving, the more clearly a frog can see it... if you ever want to catch a frog, wait to make your move until your hands are just on top of the thing- the slower you move, the more invisible you are to the frog.

So what does this have to do with innovation? 

We are so inundated with information and data over the course of our day that, much like the frog, if something is not moving (i.e. different), we ignore it. 

Only firms and products that can cut through the noise and create a stark incongruity have a shot at egging out a slice of the market.

Changes in Perception: You Are What You Eat: 

Are eggs good or bad? How about butter? Red Meat? How about cigarettes? Running? Contraception?

Each of these things has gone from bad, to good and back, in some cases multiple times. In some cases, we don't know. Other, it depends on what you believe. Here's a witticism I just thought up: Perception Predates Product. People's belief systems and conclusions about what they like or don't like exist long before you got there. So saying you've got a better mousetrap means bunk to me if mousetraps aren't broken for me.

New Knowledge:  

Three times a year, The Economist publishes a series of articles on emerging technology called Technology Quarterly. To give you an idea of the kind of stuff TQ covers, this most recent iteration had stories on self-driving cars, energy weapons (literally, lightsabers), and a new kind of toilet that can cut down on occurrences of diarrhea, cholera, dysentery, and other third world diseases which kill hundreds of thousands in underdeveloped countries.

Not all of these ideas will make it to market, and more still may never see the light of day- but a couple of them will get through, and its on those leaps that the entrepreneur must focus their energy.

SWOT analysis of Google

My love affair with Ruby on Rails

I was never big on coding.

My undergrad degree was in Computer Network and Information Systems, and about 25-30% of our curriculum focused on writing code and application development. And I hated most of it.

I was always more interested in The Big Picture; how to make code do cool stuff, and how that cool stuff can make people's lives better, or solve their problems. The problem with this approach of course is that, to get to the 'solve a problem' strata of Product Development, you need to master each of the lesser strata:

• What language will you use? 
• What is the syntax of that language? How do you define a method in that language?
• How does the language organize it's data?

Each of the above points abstracts into the one that follows it, and at any given step, the choice you've made may prove to be the wrong one based on your needs. It can get ugly, and I never liked it. Give me a tool that Just Works, and let me focus on designing a killer UI/UX.

At some point, language developers started to get the hint: the emphasis now is no longer on PHP vs. Perl (or tcl, which is why Zipcar is screwed, by the way), but on how you can make these languages dance. And in order to make languages dance, you need frameworks.

Frameworks basically abstract the actual writing of code into APIs and objects which, from the app developers standpoint, are black boxes: I don't care how you capture a user's name and e-mail address, just that you capture it.

There are lots of different kinds of frameworks out there, but because this is 2012, and nobody is making apps for your desktop anymore (unless you use a Mac, more on that later), for the time being I am going to use the word 'framework' to mean 'web application framework.' In other words,  an app that 'lives' in the cloud (as opposed to on your desktop).

There are a couple of pretty solid frameworks out there that are based on popular programming languages with robust documentation and user communities: Django (Python), Joomla (PHP), Struts (Java). One that's recently been making waves in the application development community is Clojure, which is based on LISP of all languages.

But the framework that's changing the world is Ruby on Rails. And I'm in love with it.

What is Ruby on Rails (hereafter referred to simply as 'Rails')? Let's break it down.

Ruby is a scripting language, like Python and Perl- no more, no less. You can write a Ruby script to create backups on your files, rename a bunch of directories, or send you an e-mail every time a file on your computer changes.

What sets Ruby apart from its contemporaries is its distinctly 'human' design. It is designed to a) make writing code easy, painless, and most importantly, not surprising, and b) the emphasis it places on the developer instead of the machine.

Rails is the most popular framework for Ruby. Rails is written in Ruby (duh), but what it also does that very few web frameworks before it is place an emphasis on translating your ideas into code for you.

If you have Ruby on Rails installed, here's how you create an application:

rails new myApplication

That's it. One command, and you just created an application that will run. Granted, it's an application that won't do anything, but that one command created somewhere on the order of 10 directories and 50 files that you would otherwise have to create yourself. As someone who does not pine to write code, but would rather spend his time designing and architecting the application, this is like manna from heaven.

Ruby on Rails makes it ridiculously easy to create a solid web app and worry about the other stuff later. This is valuable to businesses because they can get a few generalists and have a good-enough app up and running in no time. Then, if/when it starts to outgrow the outsourced cloud model, hire a sysadmin to maintain the infrastructure. As your business scales, you can scale your workforce. Ruby on Rails makes it easy to add a layer of abstraction to parts of your web app so that when the time comes to take control of all that Other Stuff, you don't need to completely re-architect your product: just update a view lines of code, bounce your server, and you're done.

Rails as a framework embraces a philosophy called 'Convention over Configuration,' which is evident in the command above. Rails assumes that your app (and the files that make it up) will be arranged and accessed in a certain way, and leaves you to change it if you need to structure your app differently

This Convention over Configuration paradigm is also evident in the rails generate command. This is where the real power of Rails lies. Rails embraces an architecture called Model/View/Controller, meaning the app is split into three key components: data (model), UI (view), and business logic (controller). Rails allows you to build all three of these with minimal effort using the generate command.

rails generate model user will create all the files necessary to create a model for your users. You can even specify what data you want to collect about your users when you invoke the command:

rails generate model user id:integer firstname:string lastname:string

I'll probably be writing more about Ruby on Rails as I work on my app prototype, StormCloud, but for now, here's some further reading:

Git/GitHub: Git is a lightweight and fast version control system that Ruby is designed to integrate tightly with. GitHub is a free public hosting site for Git repositories.  

Heroku: Heroku offers free hosting for web apps, and Rails apps in particular. Heroku makes it ridiculously easy to deploy apps and prototypes to Production, which if you're looking to build a business, is both crucial and unbelievably valuable to businesses.