Managing people

Pick the right people

Why? Because of all the variables that go into the success or failure of a business, the people involved by far have the greatest impact. The right people can save a floundering project, where the wrong ones will snatch defeat from the jaws of victory every time. Despite this, many companies put more effort into selecting a new laser printer than they do picking job candidates.

How? Design a specific hiring process to filter out all but the very best. Know the research that has been done and how to tell the difference between average performers and superstars. When you know you have a superstar, hire them. Don't hire anyone else.

Treat them like gold

Why? "People are our most valuable resource". You hear it a lot, but rarely see it in action. Replacing people is one of the most expensive things a company has to do. Consider the lost expertise and knowledge, lost time finding and interviewing new candidates, administrative setup costs, training time for new hires (including time spent by existing employees to actually do the training), lost efficiency while they are getting the hang of things, plus don't underestimate the damage a dissatisfied worker can do to the morale of others! It's far less expensive to just keep your people happy. Not only will it be easier to keep them around, but they will be more productive too.

How? Most job dissatisfaction comes from two things - interpersonal problems and lifestyle issues. People want to work in an environment they enjoy, where they feel valued and appreciated. That means offices, not cubicles, with windows looking outside and doors they can close. It means comfortable chairs, modern computer systems, widescreen monitors, and being able to decorate and listen to music. It means fly them first class and put them up in suites. It means a louge for them to relax in, and free drinks in the fridge. But most of all, it means you listen to them when they bring concerns to your attention. Most people won't talk to their boss about a problem unless it really bothers them. If something has been brought to your attention more than once, it's affecting morale and it needs to be fixed.

Make their job easy

Why? Great people are self-motivated. They will keep driving forward until they encounter something outside of their control that slows them down.

How? When you've got a great team working on a project, the manager's most important job becomes that of an advance scout, running ahead and clearing the way. Keep your team from being interrupted and harrassed by outside parties. Protect them from distractions and complexities by filtering out all the project related "noise" that's not directly relevant to them.

Research & Design

Question everything early

Why? Because the worst possible time to ask the question "How well does our program scale?" is when your servers crash from the unexpected rush of enthusiastic customers who very shortly will be taking their business to your competition. Because it's too late to revamp your security procedures after your source code has been leaked to the public. And because "Why didn't we think of that?" is a question you never want to have to ask.

How? Build a culture where decisions are products of reasoning, not assumptions. Tell people what decisions you are making, and why. Encourage them to ask questions and help them understand the marketplace and goals so they can make better decisions on their own. Be open to new ideas and reward ones that have a positive impact.

Be flexible

Why? You'll never stand out if you just do the same thing everybody else does. To succeed in software you have to innovate. That means letting go of some preconceived notions and opening up to new possibilities.

How? You've hired intelligent, skilled, experienced, educated, motivated people, right? Listen to what they tell you. If half your team keeps going on about how much better a program would be if it were written another way or in a different language, let them try it. It might work and it might not, but in this business, it's ok to strike out a few times in order to get that one home run.

Generalize, don't duplicate

Why? Having the same or similar code in lots of different places is a nightmare. It's impossible to remember, impossible to maintain, and impossible to track. It causes confusion and miscommunication among the developers, and incompatabilities and inconsistencies in your programs. Keeping general code resources simplifies testing, dependency tracking, and even makes it easier for new developers to learn the ropes.

How? Depending on your tools, you can use header files, global objects, DLLs, custom libraries, cut-and-paste constants, whatever. Most programmers love making general purpose tools anyway because it saves them time and effort, so you should have no shortage of enthusiasm.

Scheduling

Fit schedules to reality, not the other way around

Why? Some schedules exist for deadlines and accountability, others for planning and information. I am referring to the latter. It takes X amount of time to do Y amount of work. Trying to squeeze Y into X-1 might seem possible, but it's not; you just end up with Y-1 work getting done. It might look and feel like a finished project, but somewhere along the line some corners were cut, and you won't know which ones until it's too late to fix them, if you find out at all.

How? A schedule tells you how long, by best estimate, it will take to achieve various goals. It is normal for these estimates to change, and a good project manager embraces this. They are a planning tool, and should be used to coordinate your development with your marketing and production teams. They are not an excuse to push people into overtime or deliver an incomplete product. If your team is having trouble keeping their schedule realistic, then you need to understand why before making any decisions.

Be flexible

Why? Situations change. People are sick or have off-days. They plow through a piece of code in a caffeineated rush or discover it's already available under a free license. Testing turns up unexpected problems or a certain task turns out to be a lot more complicated than everyone thought it would.

How? Embrace the idea that programming is not an assembly-line process. It is a creative process where quality is a product of many different variables - obviously skill and technique, sure, but also a good deal of luck.

Eyes on the prize

Why? Is it more important to ship what you have or to have something worth shipping? If you've been working on something for two years, and when it finally goes out the door it's just crap because someone in marketing put out a release date too soon and you wanted to meet the schedule, you've not only wasted all that time and money, but you've demoralized your team, driven off your customers, and given your competition a leg up. It's not worth it.

How? Always keep your goals in mind when making scheduling decisions. My best code has been rewritten from scratch no less than five times, and each time it has gotten significantly better. Some designs are discarded completely, others show promise and are polished and enhanced. Eventually you end up with a shiny bauble of a program that is efficient, elegant, and easy to use. The discarded efforts don't matter at that point - what matters is the finished product, and the fact that both your customers and your developers are happy with the result.

Testing & QA

Design it in from day 1 (automate wherever possible)

Why? If you want your program to do what it was designed to do, each unit of code must be tested. While it is virtually impossible to backtrack and test all the dependencies and elements of a finished piece of software, it is trivial to build testing support in from the beginning, and it even helps track down bugs earlier in the development process.

How? Require that each finalized unit of code include some sort of test procedure. It can be included in the code or separate from it, depending on whether the final product will be using the test feature and how concerned you are about bloat. Automated testing is the biggest time saver for any QA team. If every code unit in a project included a thorough automated test procedure, the entire project (or any portion of it) could be unit tested with a single command. Sure, it might take a week to finish, but for that kind of peace of mind, who cares?

Keep the teams talking

Why? The developers put out code they are proud of, the testers poke holes in it. Too often, they feel they are working cross-purposes. To get around this problem and encourage the teams to cooperate and remember they are all working towards the same goal, you have to keep them talking to each other from the beginning.

How? Your testers need more than just a test plan and a copy of the program. They need to be involved from the early stages of development, reading design documents and attending meetings. Give them access to the code base early on so they can help develop the automated testing processes and interact with the programmers. Like puppies and kittens, if they grow up together, they will continue to get along later.

Don't underestimate usability

Why? Just because a product does what it was designed to do doesn't mean the users are going to like it. Users have expectations that may be completely at odds with your design, and if so, you can expect a lukewarm reception at best. The most successful products are those that work exactly the way their users expect them to. Why do screws tighten to the right? I have no idea, but I guarantee if you make one that tightens to the left, you're going to have a hard time getting people to pay for it.

How? Do your research, both before and during development. Find people who have never seen your product before and watch them use it. Do they try to use keyboard shortcuts that don't exist? Do they look in the wrong menu for options? Are they confused by the interface? Take careful notes of how they use the program and how they feel about it. This is usability.

Marketing

Know your target

Why? You can't sell ice cubes to eskimos. In order to position your product in a market, you absolutely must know what the market is like first. Sometimes you'll have to modify your product to fit in the marketplace...and sometimes, you'll have to change your marketplace to better suit your product. And you'll always have to tailor your pitch to your audience.

How? In an established market, there's often pre-existing research. If you're targeting an obscure niche, you might create a user community website or offer discounted pre-registration as a way to get information. Whatever resources you use, understanding your target audience is critical to successful marketing.

Plan and coordinate your campaign

Why? The biggest buzz always surrounds the best laid out marketing campaigns. Targeted ads, alternative reality games, concurrent releases with complimentary products, promotions and events, these things can really wind up the awareness and anticipation for a product.

How? You want your audience to hear about you from multiple sources. If you're marketing a new video game to DC area 20-something gamers, you'll want to send demos to game bloggers and magazines, arrange for shelf space at Game Stop et al, create an online community site with purchase and download options, offer early access for pre-orders, have a kickoff event in the area with discount coupons, giveaways, and a playable demo, consider advertising on the Metro...you get the idea.

Manage expectations

Why? Publicity can be great, but it can also be dangerous. Too early and you risk copycats, too late and you can't build up a launch. But even a great launch can't save a product that doesn't live up to expectations. Be careful what your customers think you're promising.

How? Give the development and testing teams a chance to look over all marketing material before it goes out. Just because someone casually remarked that a particular feature was going to be included in the release doesn't mean it actually made it in. Your developers will certainly notice these. And just because a product was intended to solve a particular problem doesn't mean it actually does...or does it well. Count on your testers to tell you.