Anyone who works in the Silicon Valley knows the fable of the company that achieves spectacular success, then moves into new luxurious headquarters, and then immediately starts its decline. In this fable, the "new headquarters" event equates to "jumping the shark ". Certainly, there is no scientific basis for "demise by new headquarters," but every time I drive by the still empty excite@home monument or the former SGI headquarters (the new Google headquarters, btw) with its contemplation fountain set amid lush manicured gardens, I wonder.

For many rapidly growing technology companies, "new opulent headquarters" seem to mark the point where a once innovative and agile company has become big, slow, and distracted. The relevant question for me is whether or not a company's attitude toward operational infrastructure such as facilities, HR, and internal information systems is an indicator of its ability to resist decay into a bloated, slothful, has been.

A technology startup begins in a state of simplicity and focus - some ideas, a few people and little else to get in the way. As the business grows, however, sources of complexity and distraction seem to appear from every direction.

The source I found most surprising, (when I last helped start a software business back in '96), was the operational overhead that came with setting up an office, which continued to grow as we got larger. Before we knew it we were dealing with real estate leases, leased-lines, routers, VPNs, servers, workstations, firewalls, DMZs, UPSs, telephone systems, voicemail systems, email systems, web servers & website management software, accounting software, sales & marketing software, software development software, groupware, IT support staff, attorneys, and many other things - none of which were directly related to our core business. The VP of Marketing "had to" spend numerous hours looking at color swatches to select the "right" furniture. While still a small company, an office move (within the same building) required weeks of planning, dedicated staff, and days to complete.

I remember longing wistfully for the days when the company's infrastructure fit into my backpack.

As I again venture down the startup path, it is clear that much has changed - including new tools, technologies and approaches to support operational needs. Almost everything costs less than it did in '96 (except possibly the attorneys), and there is an ever expanding set of service-based alternatives to building operational infrastructure. Most companies seem to be employing these new capabilities incrementally.

I'm interested in something more radical. By focusing almost exclusively on service-based infrastructure options, a business could operate as a sort of neo-Bedouin clan - with workers as a roaming nomadic tribe carrying laptops & cell phones and able to set up shop wherever there is an Internet connection, chairs, tables, and sources of caffeine. "Going Bedouin" is an interesting concept, but key questions naturally arise:

• "How do you do it?"
• "Why do it? What are the benefits?"
• "What are the challenges?"

Given peoples' experience with telecommuting and distributed team projects from the open source community, a neo-Bedouin approach is not as hard to envision as it once may have been. The requirements for a neo-Bedouin business, however, go further and must include support for all business functions (such as sales, marketing, finance, engineering and customer support). A neo-Bedouin approach can be executed through a wide variety of specific choices. Here is a sample recipe:

For me, "because you can" is almost enough reason to "go Bedouin", but there are much better reasons. Any reduction of distraction or complexity that is due to operational infrastructure is a good thing. The goal of "going Bedouin" is to create a low inertia business that takes less capital to get started and that can react with greater agility to changing conditions. Key areas of agility include:

• Team agility: Reducing the time/effort it takes to make new team members productive. Providing greater levels of flexibility in addressing team needs through short-term contracting or outsourcing.
• Information systems agility: Reducing the effort spent on systems selection, setup, and switching. Providing greater flexibility to change or extend information systems as business conditions change.
• Physical environment agility: Reducing the adverse impact of office moves, power outages, break-ins, fires, floods, earthquakes, hardware failures, stolen laptops, etc.

Reducing operational overhead through a neo-Bedouin approach can definitely produce a "less is more" result. There are, however, challenges and concerns that come with this type of approach.

One of the first concerns is security, particularly security surrounding the hosting of the company's source control repository. The security of this service as well as any of the others used by the company is a valid concern, but it must be examined from a relative risk perspective. Internet security technologies combined with service provider features can produce a risk level that is comparable to risks present in in-house approaches. Care must be taken in choosing service providers as all do not offer the same levels of security. Because credential sharing across multiple service providers is not well supported today, team members must be cautious in terms of password management and must deal with the nuisance of multiple logins.

Another challenge with implementing a neo-Bedouin approach is in getting people to overcome behavioral inertia. Many people get very used to and comfortable with traditional approaches -to large support staffs, to phones on their desks, to control over all infrastructure details, to large central facilities, etc. Things often get done a certain way because "this is how we always did it" or "this is how everybody else does it". Some people simply can't make the transition to a more minimalist approach, and for those who can change, leadership is required.

Not every type of software business can easily "go Bedouin" and neo-Bedouinism need not be absolute. Companies that sell "enterprise application software", for example, seem to require significant infrastructure solely for the purpose of suitably impressing customer representatives - e.g. giant campuses with requisite sculptures, water features, demo centers, grand entrances, executive assistants to arrange gourmet dinners and golf outings. The specifics of some businesses make outsourcing of infrastructure intensive functions difficult or impossible.

In any business, infrastructure needs will arise that are best served by "in-house" approaches. What makes a neo-Bedouin approach different than traditional approaches is the commitment to seeking service-based alternatives to building or acquiring infrastructure that must be managed, moved or otherwise dealt with. Companies that make such a commitment can focus more of their energy and their resources on building products, supporting customers, or other core business needs.

The primary reason software businesses don't "go Bedouin" is because they think they don't have to. Fatness is easy. Executives like to construct monuments. Managers like to build empires. Engineers and IT professionals like to buy and play with technology. People like to settle in and nest. As swifter, more nimble competitors enter the software technology marketplace in greater numbers; however, companies will pay an increased penalty for their fatness. Like many resource rich kingdoms that faced the Mongols, recognition of the threat may come too late.