The body and conclusions of this report do not deal with any specific people or issues at Quack.com, but instead deal with generic issues faced by any successful startup. The ideas in this report are my own, and have been formed after working in a single startup that was acquired by a larger company.  I make no gaurentee that these ideas will help (or harm) a company.  Read and apply at your own risk.

Once a high-tech start-up has had a successful launch, it must undergo many changes to become a successful company.  The report focuses on three main areas that cause problems in a growing startup, including hiring practices, employee development, and communication.

Several conclusions are drawn from the body of the report.  First, a growing startup must take into account the high cost of training employees, potential culture clash between new and old employees, and the use of contractors when hiring new employees.  Next, because of limited resources available in a startup, managers and team leaders should be hired from outside the company until developers can be trained.  Finally, grinding (the lack of forward momentum caused by constant interruptions) can be reduced by producing proper documentation, and by scheduling meetings and discussing periods before hand.

From a single computer in the back of a garage, to a multi-million dollar company with offices around the world - this is the dream of many Silicon Valley startups.  However, the path to success is not an easy one, and each company must overcome many challenges.  A handful of people must first work long hours with little or no pay to produce a workable prototype.  If successful, the company must seek first round venture capital to hire employees and produce a product.  Next, additional financing must be obtained to bring the product to market.  Many believe that once a product has been successfully shipped, the greatest risk is over.  However, the company must still face its greatest challenge - success.

This work report will focus on the challenges of transforming a high-tech startup with a successful product launch into a viable company.  Specifically, this report will focus on hiring practices, employee development, and communication issues.

It takes a particular type of person to join a startup.  He or she must be willing to take chances, manage risk, and work long hours in support of the company. Although this type of person certainly has a place growing an established company, they can not do it alone. Unfortunately, it is a lot harder for a growing company to attract the same people it did as a startup. Since the company has proven itself, the risks are significantly reduced, and thus so are the potential rewards. Without a stake in the company, developers can not be expected to work sixteen hours a day, and give up a social life for the betterment of the company.  Thus, the company must work to reinvent its hiring and management strategy.

One of the most important things to realize when hiring people is the cost of making a mistake.  When a developer is hired, he or she must be trained.  Depending on the resources available, this could take anywhere from two weeks to several months.  Not only is the new developer not very productive during the training period, but a manager or senior team member must take time away from his or her duties to train the new person.  If the new developer is not a success, this time will have been wasted.  Thus, it is important to hire the right person in the first place, and identify the people who will not workout as soon as possible.

Another problem that often occurs when hiring new people is a form of culture clash. The original developers will have put a lot of time into building the company, and during that time become quite close.  For them, work is not just a job, but also a social setting. Furthermore, most of them will be used to working long hours, and may not be very accepting of new employees only working forty-hour weeks.  Management must work to build a single corporate culture that satisfies the needs of both groups.

Instead of hiring full time employees, start-ups often hire contractors for development positions. This can help to reduce the risk of hiring full-time employees that do not work out.  If a contractor does not fit well with the company, his or her contract does not need to be renewed.  Unfortunately, there are many disadvantages of hiring contractors too.  Because they are working without job security, contractors demand higher wages than full-time employees.  Thus, in the long run, contractors are much more expensive.  Furthermore, any training and knowledge is lost when the contract ends and the contractor leaves the company.   Finally, a company can not take into account a contractor when doing long-term planning.  Therefore, whenever possible, contract developers should be avoided.

When a company grows, additional management is required to coordinate tasks and resources.  The first tendency of many companies is to promote developers from within the company to management positions.  This has several advantages over hiring someone from outside of the company.  First, the developer has experience in the area he or she will be managing, and thus should have a better idea of the work involved.  Secondly, he or she has worked with other people on the team, and knows their abilities.  Finally, the existing people on the team will not have to adjust to a new person.

Unfortunately, without training, the best developer rarely makes the best manager.  In an established company, enough resources are available to train a developer for a management position.  However, in a growing startup resources are limited, and developers are thrust into management positions with little or no training.  Without this training, the new manager is more likely to make costly mistakes that slow the development process.    Furthermore, as a manager, the developer will not be able to continue coding, and someone new will need to be trained for the job.  Finally, developers are sometimes reluctant to give up their coding duties, and may not be as happy or productive as managers.

Thus, initially, managers should be hired from outside the company.  By doing this, existing developers can continue doing what they do best - developing.  There will likely be some friction when the manager is introduced, but a good manager will quickly prove his or her worth to both developers and upper management.   Once a company has grown, and has more resources, developers who wish to advance can be properly trained as managers.

In a small company, communication is usually very simple.  If a developer encounters a problem in code, he or she can simple look across the room and ask the person who designed it. However, if this form of communication continues as the company grows, developers become inundated with questions, and are unable to make any progress.  This effect is known as grinding, and is a serious problem in many high-tech companies.  In  a growing startup, the effects are much worse because most of the questions are directed to the original developers.

Unfortunately, most developers feel the solution to grinding is worse then the problem: documentation.  During the rush to get a product out, little time is available for a developer to document his or her code or design.  At development time, this is usually not an issue since only one person needs to work on the code.  Once the product has shipped however, other developers will likely be hired to maintain and extend the code.  Without any documentation, the new developers will need to spend a significant amount of time reading the code before making any changes or enhancements.  Furthermore, they will likely have a number of questions - contributing to the grinding problem.

To reduce grinding, a company must first produce documentation for the existing design.  To do this, the developers from the original team need to take several weeks away from new development to produce basic design documents.  These documents should be produced for all deployed components, including those that will be replaced in the future.  Once the developers have created the original drafts, tech-writers can be used to polish documents, and distribute them.

To prevent a communication problem from occurring again, documentation must be developed in parallel with code.  The project plan must then accommodate this new requirement.  Developers can produce this documentation themselves, but if the resources are available, assigning a tech-writer to each team is a better solution.  Design documents should be produced for each software component before it is created, and updated as necessary.  This slows initial development of software, but it benefits the company in the long term.

No matter how much documentation is produced, developers will always need to talk with each other.  However, in a larger company, structure is needed to prevent developers from being constantly interrupted.  All meetings should be scheduled at least several hours in advance, so developers can plan their day.  Additionally, team leaders should schedule office hours each day to work with junior team members.  These sessions can be used to deal with specific problems or as drop-ins to discuss general problems.  By adding a little structure to communication, developers should experience fewer interruptions, and thus be more productive.

• It is very expensive to hire and fully train an employee who does not have the ability or desire to fit into the company’s future.
• When hiring new employees, management must consider the employee’s ability to fit into the corporate culture.
• Contract developers should be avoided wherever possible.
• A developer needs management training before he or she can become an effective team-leader or middle manager.
• A growing startup should initially hire managers from outside the company until enough resources are available to promote developers to these positions.
• Grinding can be reduced by producing proper documentation, and by scheduling meetings and discussion periods before hand.

Frauenheim, Ed. "High-tech salaries are taking off." 2000. http://www.techweek.com/articles/4-17-2000/salaries.htm (2001/04/21)

Voisin, Craig - Director of Engineering, Quack.com