Part Two
People

As a small company grows, each hiring decision is incredibly important. If your company has 30,000 employees, one "bad egg" doesn't make that much difference. If your company has four employees and you make an unwise decision hiring the fifth one, suddenly you have a problem that covers 20 percent of your staff. The next six chapters of this book are about people.

Eight
SMALL ISVs: YOU NEED
DEVELOPERS, NOT
PROGRAMMERS

A common mistake is for a small company to hire someone who was previously a success in a large company. The logic seems to make sense. If this person did such great things at XYZ Corporation, that means they are really smart, right?

In general, stuff doesn't work that way. A person can be really smart and also be a really bad fit for the challenges of a small company. Life in a small company is very different from life in a large corporation. People see the (admittedly modest) level of success I have had and assume that I must know a lot. Nonetheless, I consider it very likely that I would not be well-suited to working as an executive in a large firm. Similarly, a programmer who thrived in the environment of a big company is not likely to do well in a small ISV.

FRIDAY, MAY 9, 2003

Context is critical. Management advice can be worthless or worse if it is not appropriate for your situation. The right decisions for a big company can be fatal in a small one. Make sure you consider your context before you listen to anybody's management drivel, including mine.

I run a small independent software vendor (ISV) with no substantial outside funding. SourceGear is 6 years old and has 25 employees. I've learned plenty of interesting lessons along the way. One of the things I've learned is that a small ISV should not have any programmers.

For the purpose of this article, a programmer is someone who does nothing but code new features and (if you're lucky) fix bugs. They don't write specs. They don't write automated test cases. They don't help keep the automated build system up to date. They don't help customers work out tough problems. They don't help write documentation. They don't help with testing. They don't even read code. All they do is write new code. In a small ISV, you don't want any of these people in your company.

Instead of programmers (people who specialize in writing code), what you need are developers (people who will contribute in multiple ways to make the product successful).

My apologies if I'm trying to be too cute with my word definitions, but it really doesn't matter what terminology you use. In a small ISV you can't afford to have people who think their only responsibility is writing code. There are far too many other things to be done, all of which are critical to having a successful product. If you were a BigCo, you would just hire more specialists until every job function is covered. But as a small ISV, what you need are fewer people who are more versatile.

Boundaries vs. Flexibility

This is a really important difference between small companies and big ones:

• In a small firm, most people wear multiple hats. It simply isn't feasible to have a person who focuses on just one small area. Small companies need versatile people who are content and capable to step in and do whatever it takes to help the company succeed. One accountant or bookkeeper handles basically everything. There is often a utility infielder who is always busy, but nobody knows what they do. The key concept here is flexibility.
• Big companies have more specialists. Payroll is different from "accounts receivable," which is separate from "accounts payable." Architects do design. Programmers write code. Technical leads manage programmers. Program managers keep the spec and schedule. Product managers do positioning and message. Evangelists do, er, well, nobody really knows what evangelists do. Anyway, each person has a specific, well-defined job. The key concept here is respect for boundaries.

By the way, these are two very different cultures, and ugly things can happen when they intersect. Flexibility and boundaries don't mix very well. A person who has been successful in one of these cultures often stumbles badly when they transition to the other one.

Developers

In a small ISV, every developer is first and foremost a programmer. The bulk of their time should be spent writing code and fixing bugs. But every developer also needs to be involved in other areas such as the following:

• Spec documents
• Configuration management
• Code reviews
• Testing
• Automated tests
• Documentation
• Solving tough customer problems

Using my terminology, these things are the difference between a programmer and a developer. The developer has a much larger perspective and an ability to see the bigger picture. The programmer writes code, throws it over the wall to the testers, and waits for them to log bugs. The developer knows it is better to find and fix bugs now, since he just might be the one talking to the customer about it later.

When your team evolves from programmers to developers, your pecking order may change. Your best developer may not be the person who usually gets thrown the really tough problems. A programmer of amazing talent can be a lousy developer. Coding is a necessary but insufficient part of being a developer. Similarly, the less gifted members of your team can still distinguish themselves as excellent developers through their contributions to the non-coding parts of the product.

Frequently Asked Questions

Can't We Just Let Our Programmers Be Coders and Hire a Separate Group to Do Everything Else?

Maybe. SourceGear has tried it this way in the past, and sometimes it has worked well. But in the long run you will regret the decision to insulate your programmers from everything but code. Programmers in a small ISV have too much influence to let them have a narrow perspective. Make them see the perspective of the user. Put your programmers on the phone to help a customer with a tough problem. Your product quality will improve as you expose programmers to the consequences of the bugs they create.

Our Programmers Don't Know How to Do All This Other Stuff

Really? Surely the university CS programs are teaching SCM tools and tech support skills, right?

Yeah, my school didn't teach this stuff either.¹ It's a foregone conclusion that your programmers don't know how to do the non-coding aspects of product development. Teach them.

Formal training might play a part here, but the best learning comes from experience. Your developers need to borrow the advice of Nike and "just do it." Make sure they are allowed to fail. Let them learn from their mistakes.

____________________

Our Programmers Don't Want to Do All This Other Stuff

Some people don't want to be developers—they want to be programmers. That's OK. A programmer can have a fine career. But you and the programmer may want to talk frankly about whether your small ISV environment is the right fit.

Ultimately you can decide to manage this in whatever way makes sense for your context. I'm suggesting that every programmer in a small ISV needs to be getting involved in something beyond the code, but most rules have exceptions.

Isn't It Rare to Find a Developer Who Has Such a Diverse Skill Set?

Yep. True developers are precious. You probably can't hire them from the outside. You have to help your programmers morph to become developers.

Once they do, you may have to work very hard to keep them. When a developer leaves, he or she will become either a manager at a BigCo or a founder of their own company.

How Do Developers Get Any Code Written If They're Constantly Being Interrupted with Other Stuff?

Yep, that's a problem. I'll take this opportunity to cite Eric's Axiom of Software Management:

You can't eliminate problems,

but you can make trades

to get problems that you prefer

over the ones you have now.

Your developers still need flow time, or they will never get any code written. This problem is far preferable to the set of problems you get when you surround yourself with people who have a narrow "code-only" perspective. Try to structure your time. For example, don't try to write code and do tech support on the same day.

So Are You Saying Our Developers Have to Do All That Other Stuff?

No. Ideally, your developers still spend most (but not all) of their time writing code. If your budget allows, there are several categories of specialists that you might want to consider hiring.

"LEVEL-ONE" TECHNICAL SUPPORT

A lot of technical support work involves answering the same questions over and over. This is probably not the best use of a developer's time. Keep your developers involved in "level-two" support, diagnosing and solving customer problems that are tough and mysterious. But it's a good idea to have one or more specialists to catch all the easier stuff. We usually look for someone with good communication skills and some sort of a background in technology or science.

MANUAL TESTING, BUG-FIX VERIFICATION, AND SO ON

As long as you're building a level-one support team, overstaff it by just a little. Give them some slack time so they can be involved in a certain amount of QA work. Let them do some of the manual testing and bug-fix verification work. This will reduce the load on your developers and will dramatically slow down the burnout rate for people in pure tech support positions.

DOCUMENTATION

Have your developers write the spec or the first draft of content, but the final creation and edit of your documentation is a job best suited for someone who can spell.

SYSTEM ADMINISTRATION

Your developers probably can do sysadmin work, but there's no particular product-related reason for them to do so. Hiring a sysadmin person is one way to reduce the distractions on your developers.