Judging Startup Success

Gabriel Weinberg had a post today about when a startup can be called successful. It’s an interesting post in that it doesn’t really formulate an iron-clad ‘this is what I think’ opinion. It does a good job of looking at the question from all angles. I think the gist of the post is that there can be a lot of viewpoints around a startup and some can be orthogonal when it comes to judging success. I tend to agree.

However, there’s also another angle I didn’t see discussed. First, let me introduce an old saying in business:

Never take ‘No’ from someone who doesn’t have the power to say ‘Yes’.

I’m not 100% sure where it comes, but it’s something great to internalize. It means that you shouldn’t spend your time trying to get the approval of someone who never can or will give you that approval. That lesson can be applied to many situations, especially surrounding your happiness. Never put gauging your happiness into the hands of someone else. You’ll always be chasing that persons approval, even if that person is multiple physical people.

The same can be applied to your startup. Never tie up how successful you view your startup by seeking the acknowledgement of someone else. Someone will always come up with a different goal for you to reach “to be considered a success story.” Call it the moving the goal post axiom of startups.

This, of course, is easier with less debt and fewer investors. Keeping with the theme of Gabriels post, a $10 million offer to buy your company looks very different to a company that’s bootstrapped w/ no debt than one that’s taken on eight figures in VC funding.

This isn’t a another anti-funding rant. It’s more of a plea to figure out what it’s going to take to call your startup a success. Not what will make your friends, your extended family or parents at your kids school think that it’s a success. You.

Goodbye Facebook

This weekend i did something that i’ve been slowly inched towards for the past few months: i deleted my facebook account. this started several months ago by slashing my friends from 200 to 100 to under 70. when i originally signed up, i made two rules: only personal friends would be allowed ( no biz contacts ) and only people i’ve met in person.

What i found out was that those rules weren’t enough. soon i got leeched in to friending old grade school classmates, then my gfs friends and then old college friends. finally, the dam broke with my first hs friend. since my hs was very small ( under 400 people total ), everyone knew everyone else. so one friend quickly morphed into 70. suddenly, i’m pulled back into the old, uncomfortable world of tenuous relationships that i thought i left behind over the years. you have to watch what you say because sally might see it, etc…

What started as a chance to make communicating with family and friends easier transformed into a virtual dinner party, where everyone exchanges vacuous small talk. plus, frankly, there’s a reason why i still only talked to the same two dozen or so people on facebook that i do in real life: they’re my friends and we have stuff in common. so i’m reducing the noise in my life and focusing on what’s actually important.

Not mentioned above is all of the crappy ways facebook is currently operating. that was just icing on the cake. I’ve written about how facebook is trampling all over peoples privacy. yes, you can turn most of it off. that doesn’t change the fact that it’s just a slimy way to act.

Startup Product Development: Simple Now vs. Complex Later

When starting any software project, there’s an age old argument: should we build something simple that solves our current problem or should we use an existing product that’s more complex, but more feature rich, since we know that’s where we’re going to end up in the future?

This is especially true when starting a company because you don’t want to get into a situation where you have something that won’t scale up to handle your impending traffic and users. (Your company is going to be a huge success right? )

One side of the argument says to start simple and solve the problem(s) at hand. That’s not the same as making short sighted, possibly limiting, decisions. It means trusting that your engineering staff can handle any iterative changes required to support your changing needs. Understand any tradeoffs in performance & scalability that you’re making now in exchange for speed & time to market.

The other side of the argument is to target something that is more complex, but that solves more complex problems. The thinking is that when you eventually reach the point where you have the more complex problems, your solution will be waiting there, dormant, ready to be turned on. The proposed benefit is that you won’t end up with something simple that you need to trash once it outgrows your needs. You can grow into your product as needed.

However, in my experience, product development rarely, if ever, happens that way.

I recently ran into this very situation last week while talking to a startup founder. He had a client that needed some simple web sites built. However, the client believed that his needs would grow to require a more full-featured CMS platform. The founder reasoned that they should just start with the CMS, so when the need arises, it will take a minimal amount of effort to support the additional complexity.

I argued the opposite. Making the “just flip a switch” assumption ignores a large swath of other assumptions, any of which could prove to be a giant roadblock:

FYI: these assumptions are not mutually exclusive. You can ( and probably will ) encounter one or more of them.

  • That you’re actually going to need the complexity – Sad to say, but sometimes the need just doesn’t materialize.
  • That you understand all of your futures needs enough to select a product that would solve them.Premature optimization is the root of all evil. Everyone loves to make predictions and be proven right. In reality, it almost never works out that way. You’re not omniscient. If you’re doing Customer Development ( you are, aren’t you? ), you’ll be taking your direction from your eventual market anyway. Why make some of the most critical decisions about your company when you have the least amount of information possible?
  • That the product you picked can actually solve your future needs – If you’re like most companies, an exhaustive product evaluation isn’t in your initial project plan.
  • That, in the time between implementing the simple solution and needing the more complex solution, nothing changes with the product that you’ve chosen that could impede your transition – Products change & evolve. New versions are introduced, sometimes with backwards incompatible changes. Even understanding any version changes and testing your product for any issues is going to be a non-trivial effort.
  • The cost of maintaining and administrating the product you’ve selected is worth the trouble – Maintenance, Backups, database updates, security updates, etc… are all factors to consider when evaluating any product. If you don’t stay on top of updates ( especially security updates ) you can find yourself in a nightmare scenario.
  • That the effort it takes implement your product in the short term allows for an easy transition to the more complex solution in the future – There’s a good chance that you’ll be new to whatever product you choose. There’s an even better chance that, however you initially use it, that your usuage won’t be optimal.

Those are just a few to keep in mind. Any one of those assumptions can cost you time and money. Both are precious resources in a startup.

However, an oft neglected repercussion of building too much too quickly is that the extra functionality can calcify your product and make it very rigid. Releases become more complex, new features take longer to implement and bugs take longer to fix. You can find yourself a prisoner of your product, maintaining functionality and features that no one ( or very few ) people use. It can demoralize a engineering team, making them more and more susceptible to the nuclear option: the big rewrite.

I think the tendency to lean towards a more exhaustive solution upfront comes from a time when the effort require to change software was much higher than it is today. When systems were written in C, C++, Perl or even Java, making changes was a large undertaking. The thought of possibly throwing away chunks of code was nerve racking.  It represented a huge investment in time and money. However, with todays rapid development languages and frameworks like Ruby/Rails & Python/Django, the investment required to create something, both in time and money, is rapidly shrinking.

To me, for any new product development effort to succeed, you should do three things:

  • Start simply and build only what you need, nothing more.
  • Pick a platform / language / framework that allows you to pivot and change direction easily.
  • Hire good engineers that are experienced with different technologies and can change and adapt to different technology needs. This will by far the hardest, but it can be done.

A Part-Time CTO

For the longest time, I’ve debated about my real sweet spot in the technology realm. I was never one of those hardcore engineers who’s going to crank out reams of code over a mt dew fueled night. However, I was also never one for pure management.  I’ve always straddled the fence between the two.  Everywhere I’ve gone, people have commented on my one, innate ability: to be able to discuss technology at both a business level in addition to a very nuts-and-bolts level.

I was always someone who could have real discussions with non-technology people about strategy, direction and overall IT governance without them looking at me as ‘just a coder’ or ‘engineer’.  At the same time, I can actually act as a technical lead / architect / lead engineer / whatever and execute on whatever vision & direction we needed, which includes actively writing code.

Well, It turns out, that’s a highly desirable, and, apparently, rare skill.  For the past 2-3 years, I’ve been informally helping other CEOs, startup founders and VPs understand their technology needs and requirements, even sometimes partnering with them to build prototypes and plans for their companies.

About 6 months ago, I found a blog by Dr. Tony Karrer called “SoCal CTO“.  His writing really resonated with me.  Two posts in particular, “Startup CTO or Developer” and “Part-Time Startup CTO” seemed to describe what I’ve been doing informally for the past few years.  Dr. Karrer was nice enough to allow me to pick his brain about two months ago.  After that, my mind was made up.  I had a knack for this and it seemed like something I should formalize & pursue.

So with that I’m formally announcing A Part-Time CTO, a boutique consulting service specializing on CTO, Technical Advisor and Assessment level consulting.  I’m focusing on small / medium sized startups who need help with their technology needs, either because they’re current management is non-technical or they’re too focused on the day to day engineering to attack longer term goals and needs.  These clients are not in need of full time, dedicated help because business doesn’t necessarily require it. For example, they employ a outside firm to do all of their development, but they need someone to act as a liaison.  I provide a nice middle ground between not having anyone and trying to justify a full time CTO.

I’ve actually been I’ve been actively seeking clients for the past two months and the response has been overwhelming.  My pitch instantly resonates with founders, both technical and non-technical.  It’s been a fun ride that’s just getting started.  Also, a note to anyone thinks that this is some ivory-tower related role: it’s not.  In most of my clients, it’s a given that I’ll be helping to actively develop in some capacity.

What does this mean for 1530?  Well, 1530 isn’t going anywhere.  A Part-Time CTO is just that: part-time and as needed.  1530 will remain my main endeavor, with A Part-Time CTO augmenting it.  That’s the plan for at least the next 6-9 months.  After that, who knows.  That’s the fun part about being an entrepreneur: you never know where you’ll be at all times.  You just have to kick ass and do a great job when you get there.

In the mean time, head over to the A Part-Time CTO blog, where I’ll be posting about my progress and all things CTO-ish related.  My first post is already up:

Startup Product Development: Simple Now vs. Complex Later

As always, comments and feedback are welcome.  I’d love to hear from other people out there about this. Especially since I’m part-winging this and part making it up as a I go along.


Upcoming Talk: Lean Software Development

Just a quick note that I’m giving a talk on June 9th.  It’s called “Trimming the Fat: An Into to Lean Software Development.”

Here’s the description:

Everyone is talking about Lean. Lean Startups. Lean Software Development. Waste elimination.  Kaizen. Kanban.  Value Stream Mapping. You’ve heard the buzzwords, but what do they mean? How are they related?  More importantly, how do you separate the snake oil from the usable pieces? While lean can be an alternative to typically iterative based software development processes, it’s supporting principles can be used to improve existing processes.

Different than just a re-application of lean manufacturing principles, lean software development is a carefully crafted set of principles and processes that allow you to mold your production process around achieving one thing: flow.  By optimizing flow through your development process, you can achieve increased levels of output not possible with traditional processes.  Without forcing you to adopt an entirely new development process, you can use lean principles to craft and optimize not only how you schedule software deliveries, but also how you deliver them.

This is for the Chicago ACM.  Please RSVP here.

Faux ‘going green’

It seems like you can’t go anywhere today without someone mentioning ‘going green’ as a way to help the environment. while it’s an admirable attempt, most peoples strategies are similar to ordering a diet coke at mcdonalds because they’re on a diet. in the end, you’re still at mcdonalds.

Yes, recycling your garbage is good. yes, buying stuff with less packaging is good. but you know what’s better? buying less shit. want to throw away less packaging? want to reduce the amount of garbage you throw away? stop buying useless crap. dvds, cds, books, clothes, electronics, furniture, magazines. just stop. if you really want something like that, wait 30 days. if you still want it, buy it. more often than not, you’ll find yourself forgetting about it in the first place.

Many of the going green initiatives are simply ways to charge you a bit more for a bit a bit less. instead of car pooling, go for a walk. instead of buying a new desk, look for one at a garage sale or antique store. instead of buying new books, borrow them from a library or book swapping web site.

If you’re serious about going green, commit to it. seriously reduce, don’t just fake it by buying things with reduced packaging.

Small Units of Work

When working in a small team, even a team size of 1, you need to be able to get something to a viable, usable and simple state as quickly as possible. Then, you often have to leave it alone for a while and be able to pick back up right where you left off. After all, there’s always more tasks to attack.

Working with small, defined batches not only makes it easier to make tangible progress towards some task, but it also helps with time management. Time is often critical for a small team. There are rarely large continuous blocks of time that you can sit down, settle in and really get some work done.

This goes double for entrepreneurs, stay at home parents, creative professionals, freelancers and basically anyone not working on a linear 9-5 job. You rarely get large chunks of time to sit down and crank something out. You get an hour between client calls or when your child is going down for their nap. That’s it.

When those small segments of time come up, it’s imperative to be able to pick something up and utilize the entire time to progress whatever your doing. It’s going to be almost impossible to make any sort of headway if you have to spend the first 30-40% of your time simply figuring out where you left off.

That’s why it’s important to have a core set of guidelines and patterns that you or your team follows when you work. That way, when picking something up, you will already know where things are, why they’re there, what they do, etc… You spend less time organizing and more time creating.

Form Over Function

I often focus on the function of something rather than the pretense of ‘what’s appropriate’. I simply can’t stand rationalizations where the reasoning is ‘that’s the way we’ve always done it.’ Usually, they are artificial constraints places on people to control them in some way. Either to establish some arbitrary pecking order or to quickly place someone into a established stereotype. Don’t wear white after labor day, dress for the job you want, a wedding is for the parents, etc…

For example, take mens dress shirts. Most men have worn shirts that come with two small buttons on the collar. Those actually come from english gentlemen who, while playing polo, needed a way for their collars to stay down. Why do we still need them?

Over the years, these traditions get passed down and eventually become the standard, with little regard to if they actually make sense. Growing up, I’ve always had this inner voice questioning every little thing if it didn’t make sense to me. As I’ve flowed more and more into minimalism, this conflict has been placed in the center of my life. Namely, can I justify everything in my life ( possessions, people, events, etc… ) by focusing on the value that it provides, as opposed to some culturally imposed guilt?

Quick Note on Apple/Gizmodo

As much as this ABC news article missing the point, I want to focus on something else. Maybe I missed something, but has there been a smoking gun that links Apple to the police and their actions?

The police got involved because it is a international story about confidential company property, involving a website run by an admitted attention whore & the admitted purchase of stolen goods. How could the police not get involved?

Does it say somewhere that the police can only investigate crimes where there is some degree of difficulty in obtaining evidence?