Exit Strategies

Many people have asked "What's your exit strategy?" when discussing my startup. Initially, I found this offensive, because in my mind if you build a viable business, you will have exit possibilities, should you desire one. Moreover once you are successful, you'll have a better idea of exactly how it should be done. Isn't building a business that has long term value what starting a business should be about? Eventually I gave up and decided this is one of the things I can't change, I was too idealistic, and found ways to articulate how and why the business would be acquired.

However, there really is a difference, and I don't think it's a good one. We're being blinded by the success of "easy money" stories like YouTube, where with the right secret sauce, there might be a lot of money to be made. Business is hard, and to focus on getting things right for the long term takes a totally different mindset. Seriously, do you think YouTube will be here in 20 years? 10 years? 2? It is not a long term value add to the world or society. It doesn't make my life better. It does contribute to the flow of information at near zero cost, but that isn't anything unique to YouTube. Yet YouTube is a VC's model of success.

This week, an insert in the San Diego Business Journal included an article by Robert K Weiler, CEO of Phase Forward. Weiler did a $41M IPO in 2004 and a $90M secondary public offering in May this year. Weiler writes:

Many times I've seen management teams focus on the IPO event, so they're making short term decisions. They're taking contracts and business to bring in revenue without building a service organization to support the business.

This supports my concern. We should be building businesses that provide long term sustainable value to customers. If we don't, we risk losing a lot, if the rest of the world finds us irrelevant.

Open source practices even if you aren't using open source

At High Regard Software, we're trying to make it easier to "onboard" new developers for our startup, RideGrid. We are using some open source, notably pieces of Apache Commons. Even if you are not using any open source, there is a lot that can be learned from Open Source to make it easier to do development. The argument for this is straightforward: if the tool set works for collaborators around the world, who by the way generally are working for free, it has to be really low friction. If it's too hard to volunteer their time, they'll find something else to do. These tools are awesome and only getting better. We have been using SVN for a year, and we are just starting with Maven. I'm going to discuss these two tools and their benefits for you, based on our personal experience.

SVN, or subversion, is a version control system. It runs on Mac, Windows and Linux. There are different ways to configure the server, but the way we chose to do it is using SSH. All of our developers generate an RSA public/private key pair, and email us the public key. Once they can login successfully to the mac server using SSH, they can download the source code using SVN's ability to tunnel through SSH. Therefore we end up with a very easy and secure distributed version control system. We don't have to run a VPN into our servers, nor do we have to maintain a web server with access to the code.

Maven is a build infrastructure. It is a higher level tool than Ant, it does not replace Ant. To really appreciate it, you have to try it. Without Maven, we were getting third party libraries by downloading them and checking them into our repository. Because we are using NetBeans, we then were declaring libraries differently in every developer's workspace. Each developer had to declare the installation path to these JAR files, making the onboarding process tedious and error prone. We tried some hacks around this with limited success. With Maven, we simply declare these dependencies including version numbers, and the Maven gets them for the developer and installs in their workspace. But the larger benefit is that once we are converted over to Maven, we are IDE independent in a couple of dimensions. Prior to Maven, the only way to build and deploy an instance of our product was to fire up and properly configure NetBeans. Once our conversion is done, the entire product can be built, deployed and run from the command line; the only reason to fire up Netbeans is if you need to make a change or debug the product. Moreover, if we bring someone on who prefers Eclipse, they can load the projects into Eclipse. This is because both Eclipse and Netbeans have Maven plug-ins, meaning they can read and write the Maven configuration files. I haven't used Eclipse, but in Netbeans you simply create a project as a new Maven project; some of the operations (like the Library Manager) are no longer relevant when you do this, so there is a learning curve.

These two tools are helping reduce the startup time of new engineers. If your team is doing Java development, I'm sure they can help your team too.

Software Development and the Environment

What can software leaders do to help improve the environment? Reduce the footprint we leave in the process of doing our work. Each of you may have unique ways you can do this, but there are some that could be nearly universal and I'll cover those here. The areas I've actually been involved with are listed below, followed by more details about each in terms of what to expect and the challenges you are likely to have. Each of these specifically reduces consumption of energy, and in the process, lowers production of GHGs (Green House Gases) and a collection of nasty, poisonous compounds including VOCs, CO, SO2, and NOX.

1. Work remotely.
2. Encourage alternative transit.
3. Turn off the servers.
4. Run virtual machines instead of deploying more servers.

Work Remotely: reduce trips to and from the office. To do this, your organization will probably require the development of new skills for you and your department. Don't bet on videoconferencing - it's not the same. Make sure your entire team has quality headsets so you can conference call and everyone can hear and be heard. Don't try to mix remote meetings and in person meetings - you want equality in the handicap - otherwise the local meeting takes precedence and you'll lose the remote attendees because they can't hear as well and don't have the benefit of the non verbal in person communication. Get a good conference calling service that has mute capability both for the organizer and for individual lines. Your team will probably need to prepare better for meetings - which is a side benefit. They'll need to prepare and distribute relevant material in advance. You will benefit by acquiring a remote collaboration tool; I haven't found one that is perfect yet, suggestions solicited. If you are going to try to draw, get a tablet.

Encourage Alternative transit: increase efficiency of per passenger commute. Don't get me wrong, I'm not saying this works for everyone, but when it makes sense, promote it -- people won't generally think of it on their own. Most places I've worked implicitly discourage anything but driving - they would rather know the person can stay the extra 15 minutes when necessary rather than catch the shuttle/train/bus. This is really counterproductive, because what it is doing is causing more people to use a system that has horrible scaling properties, so you end up wasting your employee's private time - thinking that this doesn't come out of your time is naive. The federal government has a program that enables you to get a tax benefit for sponsoring your employee's use of public transit or vanpools. It's a tax free bonus to the employees, and a tax benefit to you. Think about alternative transit when you lease that new building (I interviewed once with a company who was located one block from a METRO station near LAX, and the leaders didn't even know that). Make it easy for employees to get to and from the transit location.

Turn off the servers: lower electricity use. Those servers at 200W or more each, really add up. I've worked in environments where each developer's office has a row of servers on the floor, and for the most part they are powered up. Assume an average of 3 such servers per developer, and that is
3 x 250 x 24 x 365.25 = 6,500 KWH
per developer per year. If you have 100 developers, that's 600MWH. At 1,100 pounds of CO2 per MWH, this is 330 tons of CO2 annually. Staggering. Turn them off. This should be easy to make happen.

Use virtualized servers: lower electricity use. This will be easy to sell to your CFO, your safety officer, and the IT department. Those many configurations of developer test machines you need - convince your developers that they need to help the environment and your IT and energy budget by virtualizing (e.g. VMware or Parallells). You'll can probably sell this by telling your developers that this way they can always have the highest performing servers instead of the old and dusty ones that are often relegated to test. By hosting multiple configurations in one machine, you don't have the capital risk nor the energy consumption of a large number of test machines. The challenge will be that developers often don't want to deal with the extra layer of software; maybe IT will provide some help to do installs for the developers in exchange for the lower maintenance provided with fewer machines.

You can't "make it up later"

When you see a schedule challenge, followed by words like "but we'll make it up", you should be seriously suspicious. When the plan isn't working, the idea that things will magically get better in the future simply strains credibility. My inspiration for this post is Boeing's announcement today of a six month slip of their new airliner, the 787. The kicker here is that they've known about the problem for some time. Apparently it's due to a shortage of titanium fasteners. I can totally respect this challenge because it probably wasn't viewed as one of the major risks to the program. (We used to do the same thing with power supplies in our high end computer system design -- we spent a lot more time on the protocols, cache consistency, memory latency.... "easy" stuff like power was overlooked and often where we got in trouble). In fact, Boeing knew enough about this in June that it was written up in the WSJ. Then, they reported they don't need a lot of fasteners, and that they had reduced the production quantities to be able to avoid "over promising and under-delivering". Yet, a mere four months later, that's exactly what is happening. Moreover they say that it won't affect their earnings guidance. Do you believe them?

The good news is, it sounds like they came up with a new plan to try to adjust to the risk - but it wasn't enough. So it wasn't simply that "we'll make it up later", they did change the plan. But they failed to factor reality into the equation. What you'll often see is an abundance of optimism and wishful thinking. "We'll make it up".

No. You very likely won't. What will probably happen at a minimum is that some corners will be cut. Often, as in the Boeing case, the customer pays. It's a great way to lose customers, ironically, by trying to make them happy.

Focus

I saw this story this morning, about Columbus Day protests in Colorado. At the risk of being insensitive, this seems like a complete waste of energy. You can argue the relevance of the federal holiday I suppose. It was 500 years ago, and Columbus didn't really discover America, he simply introduced Europe to it. But what's the point of the protest? Draw attention to behavior we no longer tolerate?

Sometimes your employees may get emotional about past behaviors and decisions. Focus on the present, and commit to a better future with your actions, showing that you will never compromise the integrity of that future.