How do you do capacity planning?

The biggest issue that most development organizations face is deciding what projects to do and what projects not to do. A large part of this process is doing resource capacity planning. It is relatively straightforward and easy to do but is often overlooked.

So here are the basics:

• Determine the projects you want to consider
• Roughly size the effort per first line group per month
• Treat bugs and other overhead issues as projects
• Make priority decisions

The majority of the list of projects comes from product management. They collect requirements from multiple sources including standards, customers, sales, etc. Make sure these stay at the functional level. The projects should be complete solutions you deliver to customers or internal infrastructure projects. Stay away from listing components of a solution as projects otherwise you stand to not invest in all of the pieces that are required to deliver real functionality to customers.

You need to make rough estimates for the identified projects by group by month. This will let you know (or get close to knowing) whether you have the right skillsets to accomplish the projects. Check out the blog entries on schedules to see how to come up with numbers. Limit the time people spend on the rough sizing (do not go and create full schedules). You will build this skill iteratively. Set your sites on being aggressive but accomplishable.

Teams get in trouble by not legitimizing the time they spend on items like bug fixing, estimating, standards committees, vacation, etc. You should make the bigger efforts like bugfixing actual projects. You can create a miscellaneous or overhead bucket for smaller items. Allocate real time for these projects.

Once you have the data, you have to make some decisions. Do not allocate much more that 100% of your capacity (and less if possible) because you will run into unknowns and you need some flexibility. You can run people harder for short amounts of time but it is ineffective to do so for long periods of time. You must learn how to say no to some projects. Pick fewer items and spend more on them and finish them as opposed to work on lots of things at the same time -- context switches are expensive and you should attempt to not have people work on many projects simultaneously. Have a strict ordering for projects and releases so your team knows how to make tradeoffs.

Without planning your team will get frustrated and your customers will lose confidence. So plan and gain confidence of your team and customers!

More later ...

Effective execution

Here is an interesting checklist that can help you determine how effectively and how efficiently your organization is executing. The answer can obviously scale by size the size of your organization. This list is not in any order and is by no means complete but it is a good start for any sized organization.

Are test developers separate from test executers?

Do code developers develop automated unit tests?

Is functional test greater than 70% complete against absolute best?

Is integration test greater than 70% complete against absolute best?

Are there clear owners for each release/project?

Do you have proposal phase?

Do you do a proposal phase actual signoff?

Do you have a definition phase?

Do you do a definition phase actual signoff?

Are there preliminary product requirements in the proposal phase?

Are there rough engineering estimates in the proposal phase?

Is there a target release date in the proposal phase?

Are there complete product requirements in the definition phase?

Is there preliminary engineering (functional/design) specifications in the definition phase?

Is a criteria document (beyond no critical bugs) defined in the definition phase?

Are there committed detailed schedules in definition phase?

Is the more than 90% of testing automated?

Can you do a full test cycle in less than 7 days (except duration)?

Can and do code developers run an automated test suite before checkin?

Is there a 12 hour representative test (full function, representative integration)?

Do you require full functional/design specifications before checkin?

Do you require full unit test pass before code complete?

Do you have predictable releases?

Do you require code reviews before checkin?

Do you do nightly builds and pass your 12 hour test?

Do you allow adequate time in integration achieve 90% of the criteria document before release?

Do changes in the release plan require signoff and revised schedules?

Do you have at least 75% confidence in all of your schedules?

The more of these questions you can answer "yes" to, the more effective your team will be.

More later ...

How can employers and employees determine if a job is right for a person?

We seem to be heading into an upswing in hiring again. Recruiters fees are going up and it is becoming an employee's market. If an employer is going to pay more money for an employee, it is a great time to figure out if they are the right employee. It is also a wonderful time for employees to figure out what makes them happy in a job. Getting down to motivations help both sides do a better job.

I have had a number of jobs in my career and I know what the basics are that make me happy. When I was developing my list in early job seeking adventures, I had a long time friend and mentor, Larry Weber, tell me to make a spreadsheet where the rows were the items I thought were important and the columns were job opportunities. I graded on a scale of 1 to 10 where ten was the best. After I had completed that task, he asked me to weight the rows by grading how important each row was on a scale of 1 to 10. I then used this weight as a multiplication factor for the cells in a row. The total was my overall number.

What happened for me was that I discarded obvious mismatches and was usually left with a couple of choice that were close. The important part of the exercise is to think about your job in an analytical way and to determine some amount eHarmony-esque compatibility.

The items that always end up on the top of my list are:

• Is the job interesting?
• Do I like the person I will be working for?
• Do I feel that both me and the company have a reasonable chance for success?
• Do I feel I will be fairly compensated?
• Is it a short commute?

I clearly have a longer list of less important items and some of the above items are multi-faceted (e.g. interesting equates to technical, management and business challenges). My list clearly includes some objective and subjective items. It has helped me in my decision process.

So what does all this mean for the employer? When hiring it is common to mistakenly hire the wrong person. Often interviews do not reveal enough issues or they do highlight how a known issue with a candidate might play out in your environment. I plan on a 5% failure rate on ongoing hiring and a higher number when doing a large expansion.

Along with technical, leadership and interpersonal skills, it is important to examine candidate motivations. See how what you are offering lines up with what your candidate is looking for. If your candidate has not thought about what they are looking for, then ask them to do so. This will help you make sure you have a match and hopefully a long-term productive employee.

Hire well.

More later ...

What kind of employees do you want in a startup?

I am often asked about the skill sets and levels you should search for when staffing a startup company. My answer is always the same. I feel there are two types of employees that are most productive in a startup:

• Experienced people who have done it before
• Well-educated but inexperienced people

You need a foundation of people who have just done it before. Consummate engineers who know what they are doing and have both had successes and horror stories. These engineers are part of the solution. They do whatever they have to in order to help the company achieve its goals. They can do architecture work, lead project, and slough off bad news. They lead by example. They are rare and usually expensive.

You also need a group of inexperienced new college graduates and engineers with just a few years of experience. They should have more energy than you ever remember having. They don't think there are bounds. They will work day and night just to learn. They should bring some excitement and many will surprise you with what they can do.

Skip the mid-level engineers. Not in a startup anyway. They know enough to know there are problems but they cannot see the light at the end of tunnel. They are still part of the problem. They are worried about titles and salaries. They will chew up much of your management time. Many engineers never leave this stage. As your company gets more established there will be more management bandwidth for this level of employee.

Management hires should always fall into the first category of having done it before. Over-hire when it comes to managers. Get people who know the game. Get people who can talk to customers, hire people and run releases/projects. Do not let anyone who has not managed learn on the job in a startup.

Hire well.

More later ...

Managers eat alone

When I was at Apple Computer I worked for Bruce Cleveland, most recently an executive at the former Siebel. He used the phrase in the title of this entry to describe the fact that when you become a manager, you can no longer be familiar with your employees. When I worked at Sun Microsystems, Scott McNealy talked about a higher standard his managers needed to have both inside and outside Sun.

Here are some basics to think about:

• Your words are words of authority
• Stick with requirements
• You will be doing their performance reviews
• Your jokes might be taken personally

If you join a hallway discussion as a manager, many employees will take your words as direction. You might think you are only having a casual discussion and it might trigger a massive design change or schedule change before you know it. Make it clear that your team should continue on their plans. Make sure they know they are empowered to think and make decisions for themselves. Changes should be explicit, well thought out and not ad-hoc.

If you try and do your employee's jobs they will feel micromanaged and ineffective. As a manager, drive your agenda through requirements and not implementation. Implementation is your employee's job. Implementation is why they are in their jobs. You need to allow them creativity and provide them opportunities to think and grow so they can become bigger contributors later in their careers helping both you and your company or even the industry.

Remember that at sometime during the year you will write a performance review for your employees. If you and they behave as if you are only buddies, it can be a rude awakening. Familiarity can be misleading. It can make you slow to do the portion or your job where you have to be both critical and constructive. It is better to make the boundaries clear. You are their boss and will do the job in a professional and business-like manner. If you do not, you may be forced to change the relationship into a business-like one abruptly and that can turn the friendship sour.

Things you can say or discuss with a peer are trickier as a manager. If you tease an employee, they may consider it to be official criticism. If you gossip, it may be consider prejudiced or invasive. If you inquire, your employees may feel obligated to talk and feel uncomfortable. In both this and the previous paragraph it is easy to go too far and not be compassionate or human. The important thing is to be aware and unassuming.

Take your position thoughtfully and your employees will more likely take you with respect.

More later ...

How can you build camaraderie in your company?

We all want to work together well, right? While a good technical or business debate is essential in any endeavor, I believe companies accomplish more when employees work together well.

Here are some basics:

• Be clear about company and group direction
• Foster open dialog
• Respect
• Create shared experiences

It is hard to work together if you cannot agree on company direction or there are misunderstandings about company direction. Everyone in the company should be able to articulate the direction of the company -- maybe even make it a game at a company/group meeting taking turns saying the company direction and voting for the person(s) who does the best job at saying it. Clearly any divisiveness within your ranks will undermine camaraderie. Allow time for people to provide input, make timely decisions and get everyone to commit (even if they disagree). You should manage people who cannot commit appropriately.

You need to make sure people feel like they are part of the team. If employees have issues, good ideas or just information, they need ways to make them known. They need to feel that information will not be punished. You need to promote people sharing information and not keeping it close to the vest. Treat your employees like adults. Entrust them and charge them with keeping that trust. Encourage them to trust their fellow employees. Problems should be just things you solve together. Do not wait for your employees to come to you, you must engage them.

You must respect your team and you and your team must respect the rest of the company. Cynicism and sarcasm should be replaced by encouragement and suggestions and real problem solving. Set expectations with your team on respect and hold them accountable. Without respect, there is no camaraderie.

Finally, you must create shared experiences. These range from brainstorming some challenge, to working late together, to sharing meals. Shared experiences and shared challenges and ultimately shared accomplishments really make a team into a team. Acknowledge these events. Try and engage people who hang at the edges of these kind of groups (e.g. asking everyone's opinion in a room about some topic or decision).

Shared experiences are best when shared broadly. If one part of team has to work late to complete a project, it can help to have everyone work late including marketing and customer support. Clearly you have to balance this with people's schedules, when other employees had to last put in extra time, etc. The point is that it is good to find first-hand ways to understand what others are doing and to support them in any way possible including mere presence.

Set your intentions in this area and you can make a huge difference.

More later ...

How can you make positive changes in your organization?

Are you missing schedules? Do your engineers behave badly? Do you have poor quality in your products? Are you experiencing a lot of attrition? Are you having a hard time hiring? Do you want more innovation in your team?

It does not matter what kind of problems you are facing or changes you want to make, you can employ some of the same techniques to effect change. Here are some of the basics:

• Make sure both you and your employees understand why you want to make a change.
• Create a plan and declare your intentions.
• Allocate time each day or week to focus on the change including status, techniques, issues and successes.
• Figure out how to measure improvement and then measure it.
• Recognize success.

If your team understands the rationale for change, it will be easier for your team to adopt change. They do not have to agree with the rationale but they have to understand it. Make sure how this benefits the company and ultimately how it benefits them. Do not minimize this step. Take the time to have a discussion, acknowledge their viewpoints. This is where you build teamwork. This is where you get to say "we are all in this together". There is where motivation begins.

Make your intentions very clear. Do not be ambiguous. Solicit your team's help in creating a plan. Do not make it a choice thing. When you have a plan say "we are going to do x and and y and z ...". Make it a priority. Legitimize the time and don't assume your team can take on an important initiative without some tradeoffs.

The way you get something done is to spend some of your team's collective focus on it. Allocate time at each staff meeting to talk about the change or if it is a critical issue, meet each day. The act of taking time, speaking about it aloud has an effect.


If you do not measure something, you cannot improve it. Or at the every least, you cannot tell. There are lots of tools available to measure things that you might not think to be measurable. Industry tools like Six Sigma (TM) concentrate on techniques to measure things. It is easy to stop measuring along the way so pay attention and keep at it.

Finally, it is important to recognize success. Positive reinforcement. Rewards through remuneration or praise are important and will incent your employees to work on the next change you want to make.

So, go out and break some glass!

More later ...