Categories

Category Blog

The False Choice Between Enterprise IT and Startup IT

There is much to like in the new book Rework, from the founders of 37signals. The book, geared toward small businesses, startups and entrepreneurs, is a collection of common-sense and (self-described) contrarian views on everything from the work hours necessary to be successful when starting a business…

“Send people home at 5…You don’t need more hours, you need better hours.”

to the need to focus on building your company rather than on external financing or the minuscule odds of making a big payoff someday…

“You need a commitment strategy, not an exit strategy. You should be thinking about how to make your project grow and succeed, not how you’re going to jump ship. If your whole strategy is based on leaving, chances are you won’t get far in the first place.”

Much of the commentary on the book has centered around whether the success of 37signals as an independent, profitable software operation is applicable to the majority of small and internet-focused businesses.

For me, the book is one more data point confirming a theory I have held for sometime; that we are moving toward an environment in which there really are two “camps” of IT professionals (and IT shops). On one extreme are enterprise IT and those within it, and on the other startups and small businesses. As in most tribalism, each extreme is easily painted with incorrect stereotypes, and a false choice is presented between them – you can belong to one camp or the other, but not both. Its easy to look across the chasm at the other side and make little effort to understand their real challenges or what might be learned from them. If an individual moves between camps, it is very likely by leaving the enterprise world for the small-business world, never to look back.

Can Web Business Really Be Frictionless?

In the discussion of eBusiness / eCommerce / Web 2.0 companies you will frequently hear the word ‘friction’ being used, and it’s always something to be avoided. Friction is anything that will slow you down as you scale up your business model and increase revenues, from the movement of physical bits across the country, to a dependency on another firm in the middle of a transaction, to that most friction-full of items, pesky human staff. If one could only find the eBusiness model that would scale almost infinitely without the need to worry oneself with these mundane factors, especially increasing human staff, now that would be a winner. Some VCs use the term to a fault.

Certainly the growth of the web has overturned many industries, added new efficiencies and disintermediated others that no longer add value.   Yet as many of the web names we know grow larger and become a bigger part of our lives, I find myself interested less in whether they are still true to their mission statement, and more interested in whether they have underestimated the real operational requirements to supporting large customer bases and millions of transactions.

IT Project Communication and the NASA Launch Process

I’ve always been a space nut.  I was one of those nerdy kids in the 60’s-70’s who sent handwritten letters to NASA asking for mission photos, and actually received several back, which was quite a thrill. Do they still have the money to do that?  Probably not.

I’ve been thinking a lot lately about the importance of communication in large-scale IT programs, how prone to failure our programs/deployments are, and the lessons I had by listening in on the Ares 1-X launch last Fall.

While the great majority of people saw the few seconds of the actual launch on TV, I invested several hours listening to the live launch feed, which due to several factors (including a ship entering restricted waters) was pushed back multiple times and eventually took place the following day.

Why invest the time? I found myself intrigued by the communication process used between Mission Controllers* and the dozens of people on the line, each with their own accountabilities and at diverse locations around the globe. It immediately reminded me of many large-scale IT projects I have been a part of, and here’s what I took away from the experience: