INTRODUCTION

In many small and growing companies, engineering managers are often in the unique position of having to deal with the technical team and other senior managers, while simultaneously taking direction from the CEO. Too often, development managers focus only on technology, even though the nontechnical aspects of the job can have the biggest impact on a company's success. As your company grows, problems that once seemed small can grow accordingly, exploding into major disasters. I wrote Growing Software to offer advice for newer development managers about how to succeed when faced with these diverse challenges.

The role of a development manager at a small company differs from the same role in a large and stable company in many ways. For example, the development manager at a small company must often work with developers to support an immature product. Development managers must also work with the strong personalities who are attracted to the challenges faced by growing companies. But most of all, a small company's development manager must have a wide focus that includes employees, product, process, planning, technology, and customers.

In contrast, large companies typically support multiple existing products, and their processes are usually well defined and relatively static. Policies in large companies typically limit the choices of tools, techniques, and approaches that a development manager can use. The manager's role is more specific and much narrower in scope than the same role in a small firm.

Growing Software serves as a practical, hands-on guide for development managers at small companies that have moved past the initial survival stage and are trying to grow. It is intended to help the manager look ahead and deal with problems before they become unwieldy. The techniques described here are useful for small firms producing software for sale or for a software-as-a-service offering; they are not directed at software consulting businesses. Growing Software provides general advice, specific solutions, and detailed templates and spreadsheets to help development managers put general concepts into direct action.

Because the scope of the book is broad, it is written in a prescriptive style rather than an argumentative one—that is, many recommendations are not supported by exhaustive arguments as to why the techniques work well. Although this information would have greatly increased the scope of the book, it would have made it less readable.

For convenience, I use the terms development manager and development management throughout this book to describe the top software/engineering manager—whether the particular job title is chief technology officer (CTO), vice president of engineering, director of engineering, or senior engineering manager. This person manages software engineers, but he or she might also manage quality assurance, documentation, and project management groups. Although the target audience for this book is the person in charge of all of development, nontechnical managers will also be interested in the problems and solutions described here.

P2.1. Book Organization and Conventions

This book is divided into the following major sections that make it easy to use as a reference:

• Development Team

• Product and Technology

• Outside of Engineering

• Making Work Flow: Process, Projects, and Quality

• Planning the Future

Although the order of the book allows for each topic to build on earlier ones, you can jump to any section to read about a particular topic of interest.

P2.1.1. Company Growth Stages

Companies grow in stages as they progress from startup to full growth mode. The information in this book applies to one or more of these stages. Table P2-1 defines the stages according to the size and completion of the product.

Table P2-1. Stages of Startup Company Growth

Stage	Company size	Customers
Startup	Less than 12	0 to 2, with no major customers
Foothold	12 to 40	3 to 5, with one major customer
Growth	40-plus	More than 6, with 2 major customers

P2.1.2. Real-Life Accounts

Growing Software offers short narratives of real-world situations that illustrate key points; these narratives are offset from the rest of the text. Although all accounts are written in first person for consistency, the stories are a mix of the experiences of others as well as my personal experiences. Company and individual names have been removed.

P2.1.3. Spreadsheets

Spreadsheet examples are used throughout to illustrate techniques for collecting, analyzing, and displaying information to solve specific types of problems. Each is illustrated and described in the text and can be downloaded from http://www.nostarch.com/growingsoftware.htm to be used in Microsoft Excel or OpenOffice.org Calc, adjusting for each program's minor differences. The primary purpose of the examples is to teach how to analyze and solve underlying problems with a simple spreadsheet.

Although the spreadsheets can be used as is, many problems will require that you customize the basic spreadsheet layout. You can re-create a spreadsheet by typing all the fields into a spreadsheet program. Arrows point to particular cells to indicate a formula you can enter, with a description to the right or below the example. As appropriate, copy the formula across a row or column as described in the note attached to the spreadsheet. Figure P2-1 illustrates these conventions.

When entering formulas, pay attention to dollar sign ($) characters that affect how a formula reads data when it is copied from one cell to another. Not including the dollar sign character can result in incorrect calculations after the formulas are copied.

Figure P2-1. This sample spreadsheet illustrates cell instructions.

Correct formatting is also important for the spreadsheet examples. The default format for an entry is General, which will not display all values in the most appropriate ways. Formatting is implied from the examples: Dates should use Date formatting; currency amounts should use Currency formatting with zero digits after the decimal; and numbers should use Number formatting with the rounding chosen based on how many digits are of interest.

Important Differences Between Excel and OpenOffice.org Calc

OpenOffice.org Calc uses a semicolon (;) to separate fields in a formula, and Microsoft Excel uses a comma (,). This book uses commas to separate fields in all formulas. If you are working in Calc, use semicolons instead. For example, the Excel formula =WORKDAY(B3, C3) looks like this in Calc: =WORKDAY(B3; C3). A second important difference is the inter-sheet reference used to refer to cells in other worksheets. The inter-sheet reference is an exclamation point (!) in Excel but a period in Calc. For example, a formula that references the Eng sheet appears in Excel as =Eng!H3 but appears as =Eng.H3 in Calc.

P2.1.4. Templates

Growing Software also provides sample templates, surrounded by a dashed box, that you can copy as starting points for your own templates. Template instructions appear in italics; feel free to delete these instructions as you fill out the template.