| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 |
||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||||
 COLUMN
Surviving the startup phase requires maturing your development process and people  In the current business world, if you are too late to deliver a technology solution, you might as well not deliver it at all. On the other hand, if what you deliver isn't scalable, can't adapt, or has no relevance to the business problem at hand, it should be tossed on the junk heap. This creates a huge dilemma for New Economy startups, which have been forced to deliver top-notch technology at an unprecedented pace and still succeed from the get-go.
What is appropriate in the first few months of a startup will kill a company as the number of developers and interested parties on the business side grows. But if you start out in the early days carrying the chains of an overly formal methodology, creativity and innovation can be squeezed out. I believe that companies involved in development should start out with a loose methodology that allows for experimentation and rapid innovation. The next step should be a gradual shifting of gears to increase the formality of the specification and scheduling process through enforced reviews and approvals. Finally, the formal process must be applied to the implementation techniques and architecture of your systems. Then you're ready to become an IBM: A defined process from top to bottom is the essential ingredient to massive scaling of an organization. Of course, every company is different, and some of these statements are breathtaking generalizations. But this approach works for me, and I think it will work for many others. Here's why. At all stages of a company's growth, the development staff has to have a specific target to hit -- a set of screenshots and a broad description of what the system should do. In the "let's put on a show" stage, the best way to achieve that is to sit down with the business side and educate them about the technology, explaining what it can and cannot do. During this period, the development team is writing test programs that discover the limits of the various tools under consideration for implementation. The result of this phase is that the business side should define the minimal essential requirements of the system, and the development team should build it as quickly as possible. This close cooperation between the business and tech sides is vital to making sure the battlefield development decisions don't cause the project to stray from the intent of the specification. If this sounds like "extreme programming," a rapid development methodology that is getting an increasing amount of attention, that's because it has many of the same elements. This gets you to a prototype, which in today's climate can usually arouse interest from customers, more ideas from the business side, and more money from investors. In this "go to market" stage, the size of the development team and the number of stakeholders grows -- and the margin for error drops by an order of magnitude. Mistakes at all levels have a much higher cost. Customers and investors don't understand the complexities of development, and if you don't deliver for them, they go away mad. Here's where it becomes critical to re-address your organizational needs. The development process -- and the organization -- must now grow and change to support communication with these new constituents. For instance, the product specifications, which in the early stage were owned by one or two internal business people, must now be vetted by customers and possibly investors. The process of changing specifications, which in the early stage amounted to adding all good ideas that could be implemented, must be more formal, and changes must be justified based on customer need. The schedule now involves many more people and the promises that are made must be kept. The investors paying the bills and the customers counting on delivery will expect to be informed about how things are going. As CTOs, you can make this transition if you properly staff the processes. The conversation can no longer remain between the true believers -- the business and tech leaders who started the company. Now product development staffers own the specification, project managers own the schedule, and a quality assurance manager holds one of the launch keys for anything that goes out the door. The challenge is that if you want more process -- and you do -- you have to have more people to implement it. The biggest mistake I see at this stage is company leaders with the desire to grow up but who don't want to pay up for the staff to achieve their goals. Without proper staffing, process is ignored and the benevolent chaos of the early stages becomes plain old chaos. After the go to market stage comes the "growth and refinement stage," which lasts forever. In this stage, a CTO needs to extend the formal process of managing the technical specifications to managing the technology architecture. Until now, a seasoned tech staff has been left to itself to solve the business problems with as elegant an architecture as possible. Once the product has captured the attention of the market, then architecture becomes a major issue and changes that were previously within the hidden black box of technology now affect the whole company. To synchronize these changes with the customers and the market as a whole, the same kind of management processes need to be applied and staffed. It is during this phase that the operational staff of the company rises to importance, hopefully according to a plan that was developed in the go to market stage. The message here for startup CTOs is that the development equivalent of "eat your Wheaties" is "staff your process." Properly done, this approach to evolving the process and staffing of each stage of growth can result in a company that grows from infancy to adulthood without too much teenage angst. Dan Woods is CTO of CapitalThinking, an application service provider for the commercial real estate industry, in New York. He is co-author of The Developer's Guide to the Java Web Server and was previously with TheStreet.com and Time New Media.  RELATED SUBJECTS  E-CommerceSoftware DevelopmentSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
