Small Team Lean

I’ve become more and more interested in lean software development over the past 5 years. Seeing it as the next logical step to typical agile development processes, I’ve started to refine my approach to software development. If you consider agile to be the ‘how’ of developing software, lean could almost be considered the ‘why’ of development.

Unfortunately, one can’t get far into reading about lean before you recognize a key property of its application: large teams. Most of the work in lean is centered on multiple multi-person teams trying to work in unison to build and release a product. Something that doesn’t really apply to startups, especially bootstrapped ones. Knowing how productive lean can make a team, I’m keen on applying it to 1530.

So, as I’ve spent the last 1.5 years building 1530, I’ve tried to apply lean principles not only to some client work that we’ve been doing, but also to the construction of our own products. As the months progress, I’ve started to come up with small optimizations or best practices for applying lean to a small companies and teams. I’m calling this “Small Team Lean”. I’ll be posting these small tidbits on this blog. I would welcome some feedback and/or criticism.


Recently, some Chicago entrepreneurs decided to come up with a cool little thing called ScaleWell. It awards a small seed grant ( currently $1000 ) to one lucky company, some office space at OfficePort Chicago as well as access to a collection of mentors. These mentors are trustees that donate cash and their time and help out in judging the winners. As you can guess, I’m one of the trustees. I feel honored to be involved. We’re hoping to build a bigger startup community here in Chicago. I think this is a good first step to provide some altruistic help for new bootstrappers and entrepreneurs.

Last week we held our first grant party at OfficePort. We had some local media there. Check out Crains for some info as well as a small interview with Sean & Andy, two of the founders.

Make sure to keep tabs on us to be notified when the next round of applications are going to be accepted.

Sunken Costs

Jason Cohen over at the blog A Smart Bear recently wrote about the economic theory of Sunk Costs. Ironically, I recently had a long discussion with some friends about sunk costs because of a situation I found myself in last week.

Back in December, I had registered to attend a 2-day workshop here in Chicago. At $1300 for the workshop, the cost was non-trivial. Once the first day came, I found myself having some severe issues with the workshop. The reasons are not important. Suffice it to say, I was contemplating leaving by the middle of the first day, however, I found myself limping to the end. The next morning, I had a choice: I could go back for the second day or skip it and do actual work. Now, most people would think I’m nuts for wanting to skip the second day. After all, that day cost me $650. I should get my moneys worth right?


That money is gone. It’s not coming back. Going back for the second day would have a ) made my miserable and b ) cost me more money in lost work that I could have done since it was during the week. Let’s say I can make $1000 a day. Not only would that second day cost me the day, but it would also cost me another $1000. Not recognizing the true cost of things by including the opportunity cost is a grave mistake.

Lean: Ideology Not Process

Lots of people have been talking about Lean lately. Not lean, but Lean. As the buzzword de jour in the software community, there is understandably some confusion about what exactly Lean ( and Lean Software Development ) is. Is it a new process, a la RUP, XP or Scrum? Is is a new type of process a la iterative, agile or waterfall? Is it something different entirely?

Since I’m a Lean proponent, not just in development but in my life, I typically tell people that it’s really not a development process at all. Rather, it’s an ideology and that it can be applied to any number situations and scenarios. From that point of view, Lean can be applied to any development process you use. Lean is based on a few underlying principles like eliminating waste, framing and continuous improvement. It’s not a set of steps to follow in order to accomplish some goal. Think of it as existing at a higher level, above any process that can be specifically applied to a given situation.

The key to Lean is understanding and internalizing it’s principles rather than just blinding copying them and praying for the best. Hearing that Lean worked at some other place and then ordering your managers / developers to adopt it is a recipe for failure. A good parallel for this is the way that Apple approaches design & usability. They internalize it. They understand it. Other companies see the end result, copy it and hope to be as successful. Copying skips understanding. Like most things, without understanding Lean, you’ll end up with another in a long line of stories about being ‘burnt’ by the latest and greatest buzzword.

February Semantic Web Meetup

Next week is the Chicago Semantic Web Meetup being hosted at the ITA. The topic is a little different from previous meetups. Here’s the description:

With the flurry of activity we’ve had at the meetup, I decided that this meetup would be a little different. I thought that it would be a good time to get some people around a table and talk about the Semantic Web. We could talk about the Semantic Web in general: our experiences, questions, comments, etc….

So come with questions, stories, anecdotes or whatever you think.

If you ever wanted to get involved in the Semantic Web or just wanted to find out more information, please come on out. RSVP here.

Building Software You Need

All too often, software developers take ( or are forced to take ) the kitchen sink approach when adding features. Over the lifetime of a program or site, features are rarely, if ever, removed, only added. This despite the fact that every added feature increases the complexity and maintenance requirements exponentially. People should simply Write Less Code.

In that spirit, I found this post by Manton Reece very insightful. He talks about surveying his users to find out what they use. However, for me, here’s the money quote:

I eventually did remove a feature, and the survey to customers served as a nice sanity check that the feature wasn’t heavily used. The interesting part, to me, is that the feature I removed was the entire 1.0 product for Wii Transfer. Literally everything that 1.0 did is now gone.

Quite sobering. How many features of YOUR app are actually used?

Being My Own Angel Investor

Starting a company is hard work. The biggest question that you have to answer for yourself is how am I going to make money? Next after that is when am I going to make money? Call it point B. The time between that answer and when you start your company ( point A ) will be nerve wracking. Unless you’re lucky enough to start day one of your company with paying customers, you’ll need to figure out how you’ll get from point A to B as quickly as you can while still keeping yourself afloat. In short, unless your independently wealthy or have a understanding spouse, you’ll need some form of funding.

There’s basically three forms of funding: venture capital, angels ( including friends and family ) and bootstrapping. Well, there are other forms like grants and such, but they’re pretty rare and not really relevant for most startups. For several reasons I decided that venture capital was out of the question for me. That left angels and bootstrapping. Since I had no value whatsoever in my company when I started, I felt taking any sort of investment from an angel wasn’t very desirable. I would have to either take on debt, which I’m opposed to, or exchange a piece of my company. That left bootstrapping. Now, bootstrapping is not for the weak. The time between point A and B is non-deterministic and could stretch on way longer that you would think. Take your best estimate for when you’ll be profitable enough to take a salary and triple it. That’s your floor.

Some bootstrappers run head first into starting a company quickly. They take out loans, max out credit cards and sometimes dump their own cash into the business thinking that by maximizing their starting cash, they’ll shorten the time till revenue starts coming in. I believe this is a quick way to the poor house. Startups are simply too volatile to risk your personal finances ( and possibly your credit ) on. You can talk about having faith in yourself all you want. The simple fact is that for your startup to succeed, you need to be lucky….about 10 times over. The frantic, crazy against-all-odds success stories make for good press, but they’re simply the exception and not the rule.

So, if I bootstrapped, but didn’t fund myself with personal money, what did I do? Simple: Consulting. Unsexy consulting. I’m thinking long term and, in my mind, spending a year or so consulting to fill my business coffers simply made sense. I wasn’t trying to strike quickly or catch the wave of any given fad. I wanted to build a business that endures. To do that, I needed a stable cash runway similar, to an angel investment, that would give me the freedom to build the kinds of products I wanted to build. So that’s what I went out and got for myself. However, instead of talking to an angel and trying to acquire an funding in exchange for some debt or a piece of my (non valuable) company, I’ve spent the first 12 months of 1530s existence scooping up any and all consulting gigs I could get my hands on.

Now it looks like that, 18 months in, I’m able to say that we just closed a round of funding with ourselves. We have the equivalent of an 9-12 month runway in the bank. We did this all without a ) taking on any sort of debt, b ) giving away any of the company and c ) putting ourselves in the position to compromise any of our core values. All three principles that I believed in strongly when I started 1530. Not only that, but we managed to launch Awardable into a private beta thats already generating revenue. To me, that’s a home run.

In closing, believe me when I say that we’re very excited for the next 12 months. Stay tuned for some fun announcements. Oh, and if you’ve made it this far into the post and you’ve got the startup bug or just want to dabble, drop us a line. We’re always on the look out for like minded folks to work with or bring on board.

My Minimal iPhone

Last week I did something radical. I completely hid every single application on my phone from view. Everything. From then on, I used the iPhone search functionality to launch everything. Progressively, I started to show icons for the apps that I used frequently ( > 5 times a week at least ). This is the result:


Everything else, when needed, is loaded through search. However, even those apps are rarely used. The nice part of this setup is that it’s incredibly easy to find what I actually use on a day to day basis. If I can’t remember to load something up via search, I must not use it that much. This has been partly inspired by the folks over at Minimal Mac