Tuesday, April 07, 2009

10 Startup Red Flags

I've worked on a number of startups: from seed-stage through IPO, as a founder, employee, advisor, and consultant, as well as evaluating a bunch from the outside, so I've seen my share of screw-ups. There are some obvious warning signs, but sometimes these are hard to recognize except in hindsight or without prior startup experience. If you're considering working for a startup, hopefully this will give you some tips on what to look out for.

Of course, everyone should trust their gut, so if you feel something's not right, it's probably not a good fit. I'm not going to go over everything you should be looking for in an employer or even in a startup, just some warning signs that might make you think twice about what might otherwise sound like a good opportunity. On the other hand, if you're running a startup maybe these are some things to avoid. If anyone has any strong objections to these or good stories, I'd love to hear them.

1. Wacky Titles

Startups that have too many VP and C-level titles floating around are just asking for the smack-down. Who's going to do the work if everyone thinks they're an executive? Titles like SVP and EVP are silly at a startup, and a giveaway that there's been some serious shuffling or some really big egos are involved.

It's generally wrong for people to have multiple titles too. Ever met a CTO/VP Engineering or CEO/CTO? Yeah me neither. At least, I've never met someone who needed to have both of these titles. This is generally a sign of some wildly narcissitic personalities.

If you're the CEO, just be the CEO! If you're highly technical and drive the technology vision of the company, people will get it without you tacking on the CTO title.

2. A Billion Outstanding Shares

Most startups should have fewer than 50 million shares outstanding. If you get an option grant for a million shares and you're employee 25, something is funky. Maybe the CEO got his cousin from Omaha to be their lawyer or there's been some serious messing around with the cap table. Either way, it's a sign that something is amiss.

3. Lack of Technical Leadership

In my definition, to call a company a tech startup, there must be some significant technology that gives you an advantage. Just using technology isn't enough (who doesn't have a website these days?) This means there MUST be a technical founder in a startup. If you're outsourcing the all the technical work, your company probably isn't a tech startup.

It follows that an "idea guy" who "just needs to hire a few engineers" probably isn't running a tech startup. If you're the first technical employee at a startup, you're either a founder or you're a sucker.

4. A Large Number of Ex-Employees

With social networks like LinkedIn, it's easy to get a rough idea of how many people work at a given company. Of course, not everyone in the company is going to be on LinkedIn, but if a large number of people are former employees this is a really bad sign for a startup as there probably aren't that many employees to begin with. Maybe there were layoffs, which isn't a great sign, but it probably indicates a serious retention (i.e. leadership) problem.

5. An HR Department

After a certain point, all companies need someone in charge of hiring just to deal with screening, scheduling, and general process, but most startups don't fall into this bag. If the company in question is a 5 person shop and they have someone outside the core team calling you, there's something wrong. The founders or at least the hiring manager should be doing the bulk of the hiring early on - including phone screens. I think this applies up to about 50 people.

Recruiters are generally non-technical and aside from process-pushing offer little aside from their network of contacts. If you're just looking to have resumes keyword-scanned then maybe you should consider a basic mail filter. When budgets are tight this is one area you shouldn't feel bad about skimping on. Hiring is one of the main things a startup must get right, but contract recruiters aren't the way.

I actually once had a very non-technical recruiter try to give me a technical interview (including coding) over the phone. That's a REALLY bad sign.

6. Too Much Big Company Blood

There's an old joke about General Managers from a certain very large software company who think they've "built" a billion-dollar business who then fail spectacularly at starting a company when they no longer have that big company business card. Well, it's not a joke.

Startups require resourcefulness and a rolodex of enterprise customers isn't enough. People who are too far removed from doing actual work and haven't worn more than one hat are unlikely to be successful in an environment where this is a serious prerequisite.

I'm not saying that no one at a big company can succeed in a small company, but in my experience success is rarely transferrable between the two.

7. Zero Transparency

The interview is a try-out. It sets the stage for how things might work on a day-to-day basis. If your questions about funding, outstanding shares (save this for after the interview), and the general details about the company's plan go unanswered ("It's not our policy to disclose that" is the usual response), is there going to be any openness when you work there?

This one is pretty generally applicable to all hiring, but given the small size of a startup there can't be a lot of secrets and if the atmosphere is secretive to start with, how much worse will it be when the company is bigger?

If it's your company, bear this strongly in mind. "Stealth-mode" is generally unecessary and more likely harmful to your startup (and calling it stealth-mode calls you out as a noob). You may not be ready to go as far as some in how open your startup is, but consider what radical transparency can do for you.

8. Marketing Stunts

Startups need to be cash conscious. The ones that are spending money on large booths at conferences, television ads, or huge launch parties might be fun to work at, but they likely won't be around in 6 months too.

9. Too Much Money

One of the biggest threats to a startup is running out of money. But too much money can kill just as easily. VC-backed startups can find themselves in a position where there investors are trying to drive growth by pumping money into the company. Unfortunately this usually backfires.

The first thing that happens with too much money is too much hiring. You start hiring a lot of people in sales and marketing to drive revenue, and while you may still be hiring people to do real work, the weight from the top starts to push down on everything else. The focus on hiring can take away from the drive to get actual work done which means your company is going nowhere fast.

It's easy to start losing discipline when the money is flowing around, so while that $50 million looked like a lot of money when you were 20 people, when you're 100 it's nothing. Consultants, free lunches, massages, and junkets expand to use it up.

10. Lack of Focus

When the CEO says "We're going to be bigger than Google!" and you can tell he really believes it, you should:
1. Kindly thank him for taking the time to speak with you.
2. Leave the building.
3. Never speak of this again.

It's great to have a big vision and try to get others excited about it, but a startup really needs focus (What's the minimum viable product?). You can't take over the world without building a few forts first. If company management won't even engage you in a realistic discussion of the challenges the company will face, it's going to be an uphill battle.


Tuesday, March 03, 2009

Building Android from Source on a Mac

I found this whole process to be pretty straightforward just following the instructions on the Android source page.

The one problem I ran into was that I had installed a newer version of bison (2.4.1) using the MacPorts port command. This version of bison has known problems building webkit, which is part of Android.

To work around this, I removed this version of bison (port uninstall bison) and re-installed version 2.3 from source by downloading from the bison ftp site (MacPorts doesn't support anything but the latest version of a port).

With this change, everything worked just fine.

Wednesday, February 18, 2009

Configuration Management Best Practices

I've recently read a number of pieces (including this blog) that have reminded me how strongly I believe in the power of the right configuration management process to improve the efficiency and effectiveness of a software development team. I thought I would summarize some best practices that I think every development team should have in place.

Configuration management is a pretty nebulous term and conjures up visions of gargantuan "enterprise-class" systems with their own team of administrators (ClearCase, anyone?). In my mind, configuration management is simply those tools and processes you use to build, distribute, and manage your code, including version control and continuous integration.

What follows is my list of top best practices in this space. I'll leave further discussion for another time. These pretty much assume you already adhere to The Joel Test, so this list can be seen as a more rigorous set of standards (a one-step build is a definite prerequisite). Some of these seem really obvious when written down, but I'm amazed how many teams don't do these things.

1. Use an IDE-independent build tool (e.g. SCons, swtoolkit, but please not make), unless you will never build on more than one platform.
2. Consider building on more than one platform (compiler, architecture, OS) to improve code quality.
3. Run continuous integration (build and test) on every commit.
4. Keep build products and test results for every commit and make them easily accessible (indexed by revision number).
5. Commit early, commit often.
6. Limit commits to one functional change. (Don't fix multiple bugs unless they have the same fix.)
7. Make it easy for developers to run cross-platform tests in advance of committing.
8. Never commit untested code. (Shoot users of "git add --p" in the head.)
9. Make fixing build breaks your second highest priority (behind fixing production breaks).
10. For consistent builds across machines, keep all tools in your source repository (or at least make fetching them part of your build).

What other practices do you stick to?

Tuesday, February 03, 2009

Evolution Revolution

The iPhone is a revolutionary mobile device - not because of the features it provides (other smartphones provided these many years earlier), but because of the level of seamless integration of these features into the first truly personal mobile computer. The experience provided by the iPhone is causing a revolution in user behavior, allowing them to consume information in new ways in new places.

When the Palm Pre was announced at CES, there was some excitement, but on its face, the Pre is really just another company's take on the iPhone. Physical differences aside, the biggest difference between the Pre and the iPhone is the programming model. While the iPhone sticks to the Mac's native application roots, the Pre's webOS will be programmed entirely using Javascript and CSS. The webOS SDK has not been released to the public yet, but a few features that will be exposed are HTML5 local storage and a JSON-based message bus.

Javascript has been gaining more and more momentum across a wide range of application tiers from the web browser to the server-side and now to the mobile device. This probably isn't because it's the best language in the world, but it is flexible and the existing platforms support easy interaction with webservices and the DOM. Though it's not clear that there are more Javascript developers than Objective-C developers, the barrier is lower for developing on this type of platform. The tools are readily available and concepts like pointers and memory management are nowhere to be found.

Given the increasing number of platforms supporting Javascript + HTTP + HTML5, it's not inconceivable that "write-once, run anywhere" might come closer to fruition with this combo than Java ever achieved.

Here's how this architecture plays out in my mind. Javascript is the core programming language. Using a HTTP transport and JSON data format, components in different processes can perform RPCs to one another. HTML5 features like local storage and the application cache allow for an offline story (the latest build of Safari on iPhone supports this). And of course, HTML + CSS allows for a common UI platform.

HTTP as a universal calling convention is pretty interesting. We already have tons of web services in the cloud using HTTP to communicate with one another - why not extend this to include local code talking with other components. The iPhone already supports a form of this IPC using the URL handlers, basically turning your application into a web server. BugLabs exposes interfaces to its various embedded device modules through web services. It has even been suggested in the literature that every object could embed a web server. Why not use this mechanism for calling that object's methods?

The benefits for such a system are great in terms of portability, dynamism, and interoperability. While there is certainly an overhead to it (a web server in every object???), performance is looking far less important than connectedness in today's web ecosystem. Sure, people aren't writing device drivers and high-performance games in Javascript, but most everything else is being attempted with good success.

Javascript (count HTML and CSS if you like) is the only mobile code platform that has succeeded on a large scale. The ubiquity of such a de facto software platform could lead to the true component software revolution that has been talked about for years. It's already evolving on the web, but the next stop is the desktop and your mobile device.

Saturday, January 17, 2009

Learning Objective-C

Over the past year I've been working with the iPhone SDK on and off. It's a nice SDK which I won't get into the details of here, but for a good summary, check out this post. The APIs and iPhone runtime are pretty straightforward, so one of the biggest hurdles for an experienced (non-Mac) programmer is learning Objective-C.

When you first look at the language it appears to be some sort of "human-animal hybrid" formed from the mating of C++, Ruby and Perl. If you're a C++ programmer all of your experience applies, but the syntax is annoying and unnecessary (like Perl) and there's a sprinkling of Ruby-like dynamism. Once you get past these fundamental differences, it's a pretty enjoyable language to use.

Here are the resources I've found most useful for learning Objective-C.

Cocoa Dev Central Tutorial. This is a good way to get started quickly and hits the important parts of Objective-C without burying you in detail.

From C++ to Objective-C. As the title suggests, this is great for real C++ programmers who want to understand Objective-C constructs in more depth with comparisons to C++.

Introduction to The Objective-C Programming Language. Apple's Objective-C reference is more detailed and useful for understanding language arcana.

Monday, September 08, 2008

Chrome Goodies: SCons, Buildbot, and Skia

With a quick look I noticed that Google's new Chrome browser uses SCons as its build tool. This is great news! I've been a fan of SCons for quite a while and have used it on a number of projects. In my experience it's especially good for building native code in multiple configurations. I won't go into all of the benefits of SCons, but the fact that it's written in Python means scripting your build system is a breeze.

While SCons has been used by a number of open source projects out there and is supposedly used by some large software companies (VMWare, id Software) this is the most significant open source project using it. I've seen some Google engineers been lightly involved in the project in the past, so hopefully this will push further adoption. SCons is not without its issues, but it's head and shoulders above any other build tool I've used. Will this be one of the last nails in GNU make's coffin? I hope so.

Chrome also uses Buildbot (also written in Python) for its continuous integration system. Buildbot is another open source tool that I've used in the past and loved its easy configurability and extensibility.

Also interesting to note is that Chrome's source code includes the Skia graphics engine. Skia was a company acquired by Google in 2005 and its SGL (Scalable Graphics Library, nee Skia Graphics Library) engine serves as the core of Android's rendering system. This is pretty exciting given that there isn't a great vector graphics toolkit out there that is open source and is suitable for embedded. Mike Reed, the founder of Skia, has built something like 4 graphics toolkit companies and sold them, so the code should be quality. At present, the Skia code looks to be built only for use in Chrome, but I imagine it will be released standalone at some point. Look for Skia to appear in more Google products such as Google TV in the near future.

Wednesday, July 23, 2008

AtomDB - Oracle's response to Gears Mobile

I just read about AtomDB. This really sounds a lot like my GearSync proposal, but using Atom instead of Microsoft's FeedSync protocol (which I still haven't seen anyone using). The big difference from Gears appears to be the transparent model of data access.

There's a detailed paper here.