When There Are No Managers

January 2000

Nascent organizations run by inspired developers often need help with

the basics of bean-counting. Here's how to evaluate your situation,
implement stable management practices and create an effective
software engineering culture.
by Hugh Bawtree
New companies, no matter what kind of software they produce, often face serious challenges
in managing and controlling the efficiency of their work. Be it a startup or a new department
added to an established company, the chaos experienced in a new organization is the same.
Developers and managers alike soon realize they are repeating old mistakes and being saddled
with the same poor results.
This situation is most frustrating for senior developers, who know the work can be better
managed but are unable to make any permanent improvements in the process. In the last few
years, I have worked for three different organizations struggling with similar issues: a startup
run by a scientist, a manufacturing company entering a new field and a new partnership
formed around an interesting product. These experiences have taught me that, without stable,
consistent management and an engineering culture, there is no way to ensure that new
technical practices are implemented and maintained.
The Scientific Startup
Not long ago, I was contracted by a startup company to add a new feature to a research tool.
The owner had a doctorate in the research area, wrote most of the code, did all the sales and
had invested all of his money in the company. All the crucial information was in his head, he
would rather write code than manage and he did not want to change the way he operated,
despite the fact that three people were now working on the product. The company used a
continuous test-and-fix cycle, so development was never really finished.
Because the feature I was hired to develop was poorly defined, we agreed I would be paid at
an hourly rate. Practicing disciplined software engineering practices was futile because the
owner and one employee did not use basic project planning and configuration management.
Since I had been hired only to develop software, I did my best to establish frequent
communications, gather good requirements, design and write well-documented code and test
it carefully. Project planning, configuration management and system testing were out of my
hands. Frequent delays were commonplace.
The Ambitious Manufacturer
Another example of a new organization is a machine manufacturing company I worked with
that produces high-quality mechanical devices that have been enhanced in recent years by
adding computers and embedded software. The senior managers, unfortunately, had little
experience with software, having risen through the sales ranks or been hired for their business
expertise.
The companys tradition of small, customer-driven projects on which employees were given
the freedom to plan their own workalong with the responsibility of satisfying the customer
had produced a software department where large projects drifted past deadlines without

anyone exercising control. When deadlines were missed, managers tended to blame the
developers for a lack of discipline and commitment. Developers, in turn, blamed management
for its ignorance of software development and its tendency to panic.
For four years, I worked to improve processes and tools in the 20-person software
department. We were most successful in implementing configuration management, testing,
project management and documented requirements. The culture changed during those years
from an individualist, hacker-like environment to a more organized one which understood both
the need for specialistssuch as configuration manager and testerand the fact that some
problems are caused by the process itself. Each improvement came about largely through the
efforts of one dedicated person. Although I worked on all the process improvements, I believe
the successful ones were implemented only when both managers and developers were
convinced of the need for that particular improvement. Then it became a matter of simply
hiring and training the person devoted to the improvement effort. The new hire made the
practice viable by devoting all his time to setting up the procedures, tools and equipment, and
by working with the developers.
The Promising Partnership
It often happens that a group of developersin this case, former employees of the machine
manufacturing companysees an opportunity to make money developing an interesting
product. I am one of three partners in this venture. Were technical and creative, but were low
on business, marketing and sales experience. Because there is not much money and even less
time, many practices and tasks are not getting done.
So far, we have been most successful in our project management. Perhaps this is because we
pay ourselves by the hour and we are concerned about running out of cash before we deliver
our first product. We also work hard and succeed in defining and documenting the
requirements. A documented design model has been started but is incomplete due to higher
priorities. System testing is advancing because one of the partners took responsibility for
setting up a testbed and performing all the system testing himself. I am the configuration
manager, but I dont have that under control yet. All of these practices were put into place
during the first six months of the companys life. The successes are largely due to good
communication between the partners, a shared belief that doing things right the first time
saves time and money, and the partners technical expertise.
On the other hand, we have not done well sales-wise. Only one partner has experience in
sales, so the other partner and I struggle in this vital area. I tell you all this to demonstrate
that every organization has its strengths and weaknesses but that it is possible to make
tremendous improvements in a short time once the participants are educated and motivated.
Does your company fit any of these descriptions? Are you trying to change a long-established
company trait? Read on.
Where Do You Start?
Implementing management practices and a software engineering culture is a crucial first step,
but its often a hard pill to swallow for developers. We all know ways to improve development,
and most of the methodscoding standards, better tools, better testing techniques, design
protocolsinvolve our technical expertise. Unfortunately, experience has shown that
attempting to implement these techniques first is doomed to failure. For example, I tried
repeatedly to implement design and code reviews at the machine manufacturing company.
Each review was a success as judged by the participants, but the reviews ended as soon as I
stopped organizing them. The root cause was a lack of strong management and software
engineering discipline which could ensure that good practices are consistently applied.

This is why the first improvements suggested by the Software Engineering Institutes
Capability Maturity Model (CMM) are all management practices: project management,
requirements management, subcontract management, configuration management and quality
assurance. Quality assurance is a management practice in the sense that it gives the company
accurate information on which to base decisions. Together, these practices put in place the
basic management infrastructure that enables the technical process to flourish.
New Organization Characteristics
In most new organizations, you are likely to encounter project constraints along the lines of
schedule ("We must deliver by March 31"), cost ("The company cannot afford to spend any
more on this product"), quality ("This release must more stable than the last one"), staff
("Weve got to keep our head count low"), or features ("The customer has been promised all
these features, so wed better just buckle down and deliver").
But are all these constraints really valid? An artificial constraint is recognizable by its rigidity
and lack of explanation. The statement is also delivered in a manner that leaves no room for
discussion. Theoretically, being constrained in all five dimensions leaves you very little room to
manage the project. In practice, however, at least some of these constraints are truly artificial.
The uncomfortable truth is that the person delivering these statements has little
understanding or control over a project for which he is responsible, so he refuses to release
what little control he has by approving project changes. Viewed from this perspective, why
should he agree to changes in the implicit contract unless some of the changes benefit him?
Not to worry; you can get changes made in other ways. Upper managers in this situation
manage individuals instead of project attributes (that is, schedule, cost, quality, staff and
features). They may make statements to indicate they are managing such things; however,
project attributes are not nearly as visible as an individuals characteristics. The managers see
individuals much more frequently than they see reports on project attributes.
Youre much more likely to obtain the resources you request if you exhibit the desirable traits
for your company culture rather than simply concentrating on the constraints. Desirable
company traits may include working long hours when pressure is applied, giving the managers
requests top priority and giving the manager regular good news reports. I am not advocating
that you do only what pleases your manager; in the long run, that will get you into trouble.
However, you had better recognize the reality of your organization before you start on a major
project. Then you can balance the need to please your manager with the need to educate him.
As you gain your managers approval, your explanations of problems (or "opportunities for
improvement," shall we say?) may lead to the approval of resources for improvements.
Before blithely ignoring all your managers pronouncements, carefully judge which constraints
are truly artificial. Draw your conclusions from your managers actions, not his words. Have
other project leaders encountered trouble when their project missed its deadline? Does your
manager know what other projects cost or the features of the new release? Have other groups
hired co-op or summer students? Does transferring people in from another group count as a
staff increase?
As is often the case, you must perform your own investigation and present the results to your
manager as a complete package: problem and proposed solution. Then all he has to do is
approve it. In new organizations with artificial constraints, you cant expect your manager to
help you. Instead, you must work to reduce your managers workload. Provide him with the
minimum amount of information that he needs to do his job. Frankly, as a developer, I find I
have to keep relearning these techniques. They are almost directly opposed to the clearspeaking, truth-telling techniques I need to practice in my technical work.
Situational Analysis

Take a moment to jot some observations about your current organization. What are the
patterns you find so frustrating? Who are the major personalities? Why do their character
traits ensure that certain patterns are repeated? What do you think they find frustrating? Are
they motivated to change? Is anyone motivated to change? If not, what can you do to
motivate them? What nasty surprises pop up on each project? For example, is the projects
progress repeatedly halted because senior developers are pulled away to work on support
issues? Is the source code for working loads difficult or impossible to find? What prevents
these problems from being recognized and treated?
Next, compare your evaluation to a process model such as the CMM or SPICE (Software
Process Improvement and Capability Determination). The CMM is described in documents you
can freely download at http://www.sei.cmu.edu/. SPICE documents are available from
www.sqi.gu.edu.au/spice. Please take at least a quick look at these documents. They are not
as dry as you might think, and they offer a summary of the scope of each software
management and engineering practice. Refer to the sidebar for more information about which
parts are most useful. This writing and reading will bring new insights. For example, if source
code is being lost, you can find some basic rules of configuration management outlined in the
CMMs Level 2 Software Configuration Management key process area and SPICEs SUP.2
Perform Configuration Management.
You may think youre ready to jump right into some solutions at this point, but wait . . . you
need more information to complete the plan. The theoryand your experiencenow is ready to
be applied to reality.
Communication and Team-Building
Any process-improvement plan depends on the workers who must implement it. In fact, the
only true challenge is to change the developers behavior. If you can do that, tool and process
choices are trivial in comparison.
Improved motivation can cause a ten-to-one difference in developer productivity, according to
Barry Boehm (Software Engineering Economics, Prentice Hall, 1981). Unfortunately, few
people in new organizations are natural motivators. Developers are hired for their technical
skills; "allowances" are made for their lack of people skills. This means you are going to have
to work hard at drawing people out. If you have risen through the developer ranks, you
probably have poor people skills but good technical ability. New organizations tend to value
employees for their technical expertise and adherence to cultural traits. They hire and promote
people on that basis. It is also likely that none of your education has prepared you for a
management role. Now that most of your challenges are people challenges, you will have to
work doubly hard to learn and apply people skills.
I have found that the best way to understand what motivates developers is to talk to them
one on one. Have a few questions and some thoughts on the current situation ready (your
written observations of the organization should be helpful), but spend most of your time
listening. Most importantly, you should like your interviewee. If thats a challenge, you may be
surprised to discover that you can learn to like people by concentrating on their good points.
Your interviewee will sense if you do not like him and will be less likely to share his insights.
There is usually one difficult person in each group. I have found the following exercise useful
before approaching such people. Start by listing the traits you dont like; its easiest to get
started with these. As you are writing those traits down, some positive aspects of those
negative characteristics should come to mind. Write those down, too. If you dislike George
because he always objects to everything new you suggest and throws up roadblocks, write
that down. You may remember an instance where he saved you much embarrassment by
exposing a fatal flaw in your plan before you presented it to management. In one case, I could
find nothing good to say about one mans work habits, but he was always interesting to visit

and gave my daughters cookies when we went to his home. Any good trait, however trivial, is
worth writing down and remembering before you approach the person.
If you think improving communication and team building is going to take time that you dont
have, you need to reorganize your priorities. No other effort will have as big an impact on your
project. With any luck, your group will give you more ideas for improvements. If you can
follow through on just some of them, you will continue to improve your teams motivation,
leading to further improvements in productivity. Even if you dont learn anything from your
groupwhich is extremely unlikelyyour expression of genuine interest is enough to give them
hope.
Software Engineering Culture
How does a new organization create an engineering culture? The best explanation I have seen
is in Karl Wiegers book Creating a Software Engineering Culture (Dorset House, 1996). It
explores both the people and technical aspects of process improvement. The first three
chapters are devoted to explaining the following three cultural precepts:

Never let your boss or your customer talk you into doing a bad job.
People need to feel the work they do is appreciated.
Ongoing education is every group members responsibility.

Now that you have a good understanding of the organization from your own and the groups
observations and good ideas from yourself, the group and the comparisons with the CMM or
SPICE, you can begin to form a workable plan.
At this point, keep the "Serenity Prayer" in mind: "God, grant me the patience to accept those
things I can not change, the strength to change those things I can and the wisdom to know
the difference." The most important result is success, no matter how small. The odds are
against you, so set your sights low and pick only two or three initiatives.
Management Challenges
The areas of improvement most needed by new groups are in organization, life cycle and
project management.
For example, companies that frequently pull senior developers off new projects to support
released products are sabotaging their future. The best solution is to assign one of those
developers to work full time supporting released products. Unfortunately, this didnt work at
the machine manufacturing company. The developers felt obligated to respond to any call from
the field; this was part of the company culture. So we implemented another solution: We
divided the development group in two. The first group consisted of junior developers doing
full-time work on new releases, and the second was of senior developers who advised junior
developers on the new release and were available to support released products. The senior
developers were no longer directly responsible for any code in the new releases. This allowed
work to continue when the senior developers were suddenly pulled away.
Another typical problem is a manager who insists on delivering on timeno matter how ready
the software. A possible solution is a spiral-development life cycle. This way, you always can
deliver something, even if the feature set is completely inadequate, and you can at least avoid
having all your developers tied up maintaining a buggy release in the field. This technique
should be used at the machine manufacturing company, but so far, few people have made the
connection between development life cycles and software that crashes at customer sites. We
are using a spiral development life cycle in the startup partnership; it certainly relieves much
anxiety to see a partial system start working early in the project.

One of the biggest problems in most new organizations is the lack of a software engineering
culture and software engineering expertise. The most effective way to overcome this problem
is through the third cultural precept: ongoing education. A weekly seminar is a great idea for
new institutions, but it does require someone who has the time to keep it going week after
week.
What about the "ideal" situation? You are put in charge of a new project. This is a chance to do
things right. Unfortunately, you are still in the same management structure, the company
culture hasnt changed and the developers are the same ones who coded the previous
disasters. Dont expect a miracle, even with your brilliant leadership. Instead, select a few
initiatives on which to focus that most everyone agrees desperately need attention. You must
evaluate your own situation, but I suggest you consider project planning, documented
requirements and testing. You probably will need to hire from outside the developer ranks for
these positions. This tactic has the benefit of getting people with the right skills and gaining
the support of the developers who generally hate planning, documenting and testing. You may
have to accept slipping schedules due to lost loads because no one is doing configuration
management. You may have to accept last-minute rewrites of poor-quality components
because there is no design and code reviews. This is no miracle, but it is an improvement.
Now consider the worst situation: You are put in charge of a released product whose
functionality is inadequate and crashes regularly when customers use it. It should be recalled.
Upper management will not want a recall, but you can point out the relative merits of
admitting a mistake versus the continuous bad publicity over the next six to 12 months while
the problems are being fixed. Recalling the product has the additional benefit of releasing the
maintenance developers to work on new features instead of fixing problems in the field.
Whether or not the product is recalled, restart the project by reviewing the existing system
feature-by-feature and practicing triage: Which features are working; which need more work;
and which require total rewrites? Build a new schedule based on this outline and allow plenty
of time for problems not yet encountered. Then tell upper management of the new estimated
release date. They probably will argue for an earlier date, but stick to your gunsas per
Wiegers first software engineering precept. After all, there isnt much they (or you) can do
about it.
Isolate difficult-to-work-with-people (those who have poor communication skills but are
technically competent) to where they can do the most good and the least harm. Second-level
technical support often seems to be a good place. These people then get recognition for their
technical expertise, but they do not develop a lot of new code. Also, they deal primarily with
first-level technical support people, who are hired for their ability to deal with difficult people.
Specific Practice Improvements
New organizations ready to try improving specific practices usually start with one or two of the
following: requirements, configuration management and testing. Following are some example
problems and solutions from those areas.
If you are put in charge of system testing for all products, you may request configuration
management be implemented at the same time. Then volunteer to do itmanagers like
volunteers. In reality, you are saving yourself; there is no point in testing a load if you cant
recreate it.
If you are introducing configuration management, hire the best person you can to devote his
full-time energy to building reproducible loads. This can begin as simply a series of checkpoint
directoriesone for each load released to testing. The important point is to get something
working quickly. Unfortunately, the best person you can get is probably a junior programmer
with no understanding of configuration management, because upper management is unlikely
to put out big dollars for something they do not understand. So, hire the junior programmer
and train her yourself if no one else is available.

If you need an accurate picture of the health of each test load, then you need at least one
good tester. While working at the machine manufacturing company, I was lucky to find a man
experienced in testing electrical devices. We arranged a transfer from his department to ours,
and he did an excellent job in establishing a testing group. He had to learn a few things about
software, but he already knew our organization and culture. Best of all, he had the right
temperament for testing: organized, patient and persistent.
Do-it-yourself Project Management
If you need documented requirements, hire an applications expert who doesnt have any
programming skills to write the requirements. He certainly will not be tempted to specify
implementation details. The equipment manufacturing company had service technicians, so a
senior service technician wrote our requirements.
If you need project management, you will probably have to do it yourself. If you have not had
training, then spend some time with a good project management text, such as The Deadline or
the Quality Software Management series. Then start tracking the tasks and dates. Use a
simple spreadsheet or a whiteboard, if thats all you have. A project scheduling tool can make
the updating job easier, but dont waste a lot of time searching for the best one. Post the
schedule in a visible location. Keep the second cultural precept in mind: Recognize and
appreciate peoples work. Milestones reached are reasons for celebration, even if they arrive
later than scheduled.
In all of the above situations, I worked to isolate the root cause of the problem and then
looked for quick and easy ways to reduce the problem or alleviate the symptoms. Quick and
easy sounds flippant, but these practices will take a long time to bear fruit in an organization
accustomed to operating in crisis mode. If they are well established after two years, you are
doing well. You wont find most of these techniques in books; however, they have worked for
me in difficult circumstances and can work for you in similar circumstances. Essentially, these
techniques come from making do with the people and material at hand.
Six Steps
Before embarking on any improvement effort, make sure you have the support of the people
you need. Any attempt to improve your organization should follow these steps:
1.
2.
3.
4.
5.
6.

Talk to group members and managers to learn their views on the biggest problems
and the required improvements.
Analyze the results of your investigation and compare them to a process model such
as CMM or SPICE.
Develop a plan for two or three improvement initiatives.
Present the draft plan to the group and management.
Accept criticisms and revise the plan accordingly.
Repeat the presentation and revisions until a consensus is reached.

The plan will not succeed unless it has overwhelming support from the group. Therefore, the
planning and selling stages are the most important.
The rest is simply project management, for which light pressure, continuously applied, is the
best recipe for success.