Communications of the ACM
Home/Magazine Archive/November 2000 (Vol. 43, No. 11)/Thinking Objectively: Management in the Small/Full Text
Communications of the ACM
Thinking Objectively: Management in the Small
Managing the software engineering process is challenging under any circumstances. But are there significant differences between managing software development in small companies and large ones? The goals are broadly the same: delivering software as specified on time and free of defects. A written job description for a software engineering management position will likely describe the same duties and responsibilities whether it is in a large corporation or a small startup. And, on any given day the development group in a well-run startup might be indistinguishable from one in a well-run department of a large corporation.
In reality most organizations of differing sizes are not run as well as they might be and show plenty of room for the kind of improvement that can be gained by skilled management. In this column, we argue that successful management in the small requires recognizing how a number of issues common to all companies present particular problems and opportunities in small companies.
Culture and Hierarchy
When contemporary small companies form themselves, the result is often an organization with a flattened hierarchy. Software engineersand indeed many who self-select for small companies in any capacityhave a strongly meritocratic bent. Stroll through the office space of many startup companies and it is frequently impossible to distinguish the desk of the CEO from that of someone in, say, tech support. The organizational chart, if one even exists, is delineated in broad, intuitive strokes and is composed of roles and responsibilities defined more by this week's crisis than by any reified notion of corporate structure. While this does not, unfortunately, guarantee more efficient management, it does confer two important advantages from the point of view of the overall goal of delivering defect-free software on time.
First, a shorter distance between decision-makers and those in the trenches allows the software development process to stay visible and for problems such as impending schedule slip or poor performance from a contractor to be addressed before they get out of control.
Second, change is the normal condition for small companies. At some point, however, even in the midst of continuing change, a distinct company culture begins to emerge and solidify. Small companies have the advantage of establishing the essence of that culture. Everyone has witnessed the range of attitudes that come to be informally institutionalized over time. Company cultures seem to settle into pattern as soon as past experience takes the form of common expectations about the future. If success has come at the price of months of forced overtime and attrition of talented individuals, the prospect of another such project is likely to be greeted by resignation (both literal and attitudinal) rather than excitement. If failure occasions an honest examination of its causes and a realistic plan to improve, then a more productive and enjoyable workplace is possible. While doing so successfully is challenging, the greater challenge may be for the decision-makers to realize the extent to which they help to create the culture that emerges.
Discipline
The dark side of software engineering in small companies is the lack of discipline.
Large companies with established development practices (which may or may not be well implemented) that adhere to various standards like ISO900X or some software capability models, do not offer a wide range of engineering behavior to employees. A talented hacker with a propensity to wander off in the weeds and work alone will likely find him- or herself transferred to another department or forced into compliance.
More likely, such an engineer will not choose a large corporation to begin with, and will wind up at a smaller firm where he or she will be expected to be more creative and have an opportunity to "do it right." The fact that talented, well-motivated developers are frequently neither well enough trained nor experienced enough to possess a good understanding of what it actually means to do it right, is a problem. When engineers are hired into work environments lacking an active professional development program that emphasizes the advantages of discipline and best practices, there is little chance those behaviors will emerge spontaneously. Since a mature well-developed program is certainly beyond the means of most new and very small companies, mentoring, career development and the education in disciplined practices have got to be the passion and pet project of engineering management.
There are two experiences so common they can be said to form a part of whatever general software engineering culture has emerged. One is the "death march" in which the schedule slips despite long hours and seven-day work weeks, features are dropped to compensate, and the final product is inadequately tested and following its release key staff members leave the company rather than go through it all again. The other experience is being forced to abandon good practices ("doing it right"however defined) because of excessive schedule pressure.
The truth is schedule pressure often does require some corners to be cut. But which ones? The fact that just wading in and writing code is what ultimately leads to the death march in the first place ought to be a solved problem by now. Smaller, younger companies, able to build and hire from the ground up, are in a particularly strong position to design a development process that reflects a company-wide collaboration that is fast-paced and very productive. Mature and experienced managers are there for that to happen, but we believe what matters most is simple intent on the part of decision-makers. Without that the merely challenging becomes the "never-begun."
Discipline in this context is the discovery of which engineering practices favor success and are thus not optional. Such an understanding flows downhill, if not always rapidly, then inexorably. When an understanding of discipline is absent at the top, the company's mastery of its own destiny is weakened.
Our experience is that talented engineers appreciate discipline when implemented in a way that makes sense for the particular company and projectthat is, in a way that helps them succeed. Resistance to an allegedly more efficient development process that looks to mandate a certain amount of bureaucracy tends to be less a matter of principle than a simple (and justified) fear of bureaucracy itself. However, with sufficient persuasion, example and mentoring, there eventually comes that gratifying moment when an engineer understands that what is being asked is not compliance, but a greater and deeper involvement with the outcome.
Managing the Decision-Makers
There is a natural and potentially productive tension in any company between what is desirable and what is possible. The business and technical trade-offs made on the basis of experience and effective internal communication can make a product successful. But many smaller companies are struggling with the notion of communication. Making matters worse is the fact that technology carries a mystique about it, distorting decision-making in two ways.
The first is the belief that technology changes the business environment in ways it really does not. Our favorite jargon du jour is the concept of "Internet time." A harmless buzz phrase such as this turns ugly when used, as it frequently is, to advocate the abandonment of planning and other good practices in favor of moving more quickly against competition, when what's really needed is a renewed commitment to good practices. The best line of defense against such temptations for the small company is a software engineering manager who knows how to help educate less-technical decision-makers about the realities of software development (perhaps in this case by pointing out that the need to move one's product to market ahead of the competition has been true since the Bronze Age). The fact that new buzz phrases and concepts appear with regularity just means more opportunity to further educate the decision-makers.
There is a natural and potentially productive tension in any company between what is desirable and what is possible.
The mystique of technology also tempts decision-makers into overly optimistic promises. Consider a meeting in which the CEO says something like, "Higgens says we can't deliver version 27.1 in 30 days, but Smithers says it has to be done by then because we already promised it to the client." Who has not been in this meeting?
Obviously Smithers is better advised to talk to Higgens before she makes promises to the client. But better still would be for Higgens to avoid meetings like this in the first place by offering more help in the decision-making process. There are several aspects to this. First, Higgens must understand the engineering task (produce version 27.1 in a month) well enough to be confident that it really cannot be done on time. Then he must be willing (and have the ability) to talk patiently, persuasively and in plain language about why it cannot be done. And most importantly, he must be able to provide a set of achievable alternatives (such as version 27.1 in two months, or a feature subset in one).
We believe it is well within the means of less-technical decision-makers to understand the basic process of producing software. Achieving that understanding may not be a short-term project, but we believe it is an essential one because the alternative is having to make important technology-related decisions on blind faith.
Creating Policies and Procedures
If solid engineering practices are to be successfully implemented, they must be drivenas must any successfully implemented policyby senior management and seriously encouraged at all levels. Success might be measured in one or all of several ways: happier employees; retention of a fuller feature set in the end-product because of not having to trade features for time; cheaper maintenance because of higher-quality code; faster delivery of the subsequent version because of not needing to rewrite the product to rid it of the kludges tolerated in order to keep on schedule. Whatever the metric, the actual observation of success needs to be followed by a discussion of how success was linked to sane practices.
Are the barriers encountered in implementing disciplined engineering practices different in a small company than in a large company? In the ideal case, the software engineering manager in a startup has the luxury early on of identifying which practices will help the development process in his or her particular company, evangelizing other decision-makers regarding those practices, as previously mentioned, and hiring a staff eager to implement them.
This pleasant fantasy is attainable, but conditions are seldom cooperative. The first barrier likely to be encountered is simply the difficulty of understanding which practices really make sense. Should there be code reviews? Certainly, but if the staff is only three workers with a dozen open requisitions, the standard formats that employ more roles than there are employees won't work. What will work is to determine the most important goals of a code review and find a scaled-down format that meets those needs.
There does not yet exist a body of literature that defines software development standards for small companies. As we have discussed in another column, various maturity and other models arguably suited to the large organization do not scale well to the small one. This doesn't mean that some sort of maturity model can't be imagined that makes sense for a particular small company, but a reliance on established models may be futile.
A surprisingly rich source of ideas for how to manage in the small is bad past experience. Companies that ship buggy code late are relatively easy to find and any manager with experience will have worked for at least one of them. A sufficient determination to avoid mistakes observed in the past, combined with the thoughtful application of common sense can provide powerful insight into which practices could avoid a repeat of history.
Personnel
Small companies live and die on the engineering talent they are able to hire. Talent alone isn't enough, but it is essential. The explosion of software development in recent years has effects resembling the Major League Baseball expansion. When the league expands, the small pool of top-notch pitchers is thinned and the hitters go wild until yet more talented pitchers can be developed. As many have noticed, there are a lot of mediocre developers on the market. Small companies (which may not have deep pockets) that wish to remain competitive must find ways of attracting and retaining talent. However, there are limits: staffing up may need to happen quickly or not at all or the desired qualifications may simply be unavailable in a very tight market.
What does it mean to get by when there is a talent shortage? A large company with a large workforce has the advantage of enhancing career development over some years, and is able to redeploy engineers to high-need projects and to transfer troublesome or unproductive employees, replacing them internally. Companies with small staffs (or yet-to-be-hired staffs) must take great care to make best use of what is available, and to gain a sophisticated understanding of what current and potential employees are capable of doing, and what they want to do.
Companies that can only afford, or which only need, small staffs are in a surprisingly strong position to be competitive in a tight market. We cover this subject on its own in a subsequent column, but a fair summary is that talent is attracted to the potential for success and to competitive compensation (in its varied forms not limited to financial). A small, well-managed company with a good business plan and a willingness to trade four senior requisitions for two stellar ones is in a competitive position indeed. The trick lies in understanding the trade-off between numbers and talent, and in a clear understanding that the role a talented engineer plays (the willingness to take on a leadership role, for instance, and to mentor junior engineers) is at least as important as the level of his or her talent.
If two experienced and successful managers of software engineering, one in a large corporation and the other in a startup, were asked to compile a list of the most important professional engineering and management practices, it would not be surprising if the two lists were similar in most respects. After all, taking timely steps to prevent schedule slippage is equally important to both and might well be implemented the same way in both environments.
Between the ideal and the real lies the journey. For the manager in the small it is a journey of (an often uncomfortably iterative) discovery of what works, of successful education and evangelism both above and below, of both leadership and implementationall in an arena in which the ground shifts weekly. What could be more fun?
©2000 ACM 0002-0782/00/1100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.
No entries found