Code reviews

In this new millennium there are certain activities that are just good hygiene. Code reviews are one of those activities. In addition it is the quintessential poster child for how managers should make changes to development processes. I will tackle both in the following paragraphs.

As I have said in numerous writings, managers must drive change with requirements and not dictate implementation details. Managers must find a way to empower and drive engineers to accomplish all of the tasks they need to do and not just the ones they consider to be fun. Many engineers consider any process to painful and bureaucratic. The best way I have discovered to overcome these issues is to delegate the definition and monitoring of development processes to engineers. Avoid having managers dictate and drive development processes.

My favorite way to delegate processes that affect all of engineering is to establish an engineering leadership team (ELT) to represent engineering. You must populate this team with people who are not process zealots. The members must be representative and respected. Make it clear they they will not do all the code reviews. Instead they will define the process and monitor it. Make sure you allocate real time for people to spend on this. Hold them accountable. Make sure they do not take forever to do it.

Once you have the ELT in place, it is your job to give them requirements and guidance. Often I will hand the team examples of what I have seen done elsewhere as a starting point. Then my management team will give them requirements. Here are some of the requirements I might set for code reviews:

• One process across engineering including QA
• Actions must be tracked
• Code reviews and addressing the resulting critical actions must occur before other internal and external people get exposed to the code
• Code reviews must be done in a timely manner
• A checklist with a minimum amount of what needs review must be developed to engender consistency and help junior member participate
• Code review results must be documented
• Need to have a fast track process for small things

Stay away from things that are not requirements. For example, I will not say what items must be checked or what timely means. That is for the ELT to decide.

I would give the team a week or two at maximum to define the process and roll it out. I would set goals with my management team about compliance and any transition needed. I would communicate how important this is to the whole team and ask them to be proud and not defensive.

Also be careful about tools. Many engineers would rather spend their time implementing a tool to facilitate a process like code reviews before your team decides what they want. Decide first and then if appropriate find or develop a tool to help.

Measure the results like how many features and/or bugs got code reviewed relative to the total, how many critical bugs were found, and how many total bugs were found.

Make this a priority and you and your team will reap benefits.

More later ..

Thank someone each day

Recognition for what we do each day comes rarely. Many of us were brought up in homes that neither gave recognition nor modeled receiving recognition well. Recognition improves job satisfaction, encourages open communication, and reinforces good behavior.

I remember hearing a wonderful story on NPR a number of years ago about an author who had suffered from mental illness and was institutionalized in her youth. Now, many years later, she recalled an anecdote that epitomizes this topic. She had been in a communal area and heard one of the doctors calling on the phone to the maintenance department and asking "Who cleaned my office today?" She had assumed she was about to hear this doctor chide someone for inferior work. Instead, when the doctor had gotten his answer, he went on to say "Well he cleaned my office better than it has ever been cleaned, please thank him for me." The author was blown away.

You too can blow away an employee by taking the time to recognize them. It does not have to be a big public thing.

Here are some basics:

• Learn the facts (correctly pronounced named, the details of what they did)
• Go to them and do not make them come to you to thank them
• Do not mix the message with something they need to improve on (you can send that message another time)
• Find someone to thank each day
• Be sincere

Often, without recognition, employees will not feel valued or just equate good work with compensation. Neither of these outcomes are desirable. Create a culture of gratitude and it will be easier for your employees to go the extra mile for you and your company.

In this spirit, I would like to thank a number of people who have helped over time with this blog:

• LeeAundra Temescue who created my website and the accompanying look and feel for the blog (http://www.thecontrarypublicspeaker.com/).
• Bill Grosso (http://www.wgrosso.com/), Joe Strazzere (http://www.sqablogs.com/jstrazzere/), and Paul Brown (http://mult.ifario.us/) for their kind words about the blog and the book.
• My mom, Sandra Himelstein, who periodically gets on here and attempts to correct my spelling and grammar.

Be thankful and lead a better life and a better company.

More later ...

How should you manage bugs?

Managing bugs is difficult. Often bugs become a battleground within a company. Questions like which bugs to fix when or what amount of bugs is ok to ship a release with becomes unclear and divisive. It take a little process and a lot of leadership to address bug management.

Here are the basics:

• Improve quality so you do not have as many bugs
• Provide clear direction on what bugs to fix
• Track and forecast the trend and effort to meet your goals

We know that we are not perfect developers but there are some good hygiene things that all companies should adopt in order to improve quality:

• Do feature/design specifications and reviews
• Do code reviews
• Require automated passing exhaustive feature unit tests before code complete
• Determine and review root cause for bugs

It will always be better to catch bugs early or better yet never create them. You should pay attention to why bugs occur and help your organization address those reasons. One of the big issues in many companies is how to prioritize bugs. The first problem stems from ambiguous categories like priority described with P1, P2, P3, ... and the plethora of other categories like severity, customer priority, etc. While your company many need to gather the emotion and need of your customer regarding a bug, the only thing your engineers should care about is when to fix a bug. Here are my suggested categories:

• Now (either for a patch or release build)
• Must fix for a particular release
• Should fix for a particular release Future

Don't confuse your engineers with overloaded codes. Make sure that bug backlogs that "must be fixed" for a released are legitimately scheduled and are not expected to be addressed in someone's overhead or free time. Make sure product management prioritizes the bugs in the must-fix categories appropriately and that you have resources allocated to fix them.

Finally, as I said in a previous blog, you need to track the trend of bugs. If your incoming rate does not go down, it does not matter how many bugs you have fixed, you will not have a stable release. Set an outstanding bug goal for your release acceptance criteria. Forecast when you get down to the bug goal for the release and manage to the forecast. Remember that there is always a tail and if you do not defer some bugs for the next release at the end of the cycle, you may never close on the current release. Bugs are tough. Pay attention and make your products quality products.

More later ...

Process is not a substitute for leadership

When an organization is facing challenges around meeting their commitments, hiring goals, retention goals, and quality goals it is often suggested that teams improve their processes. While I have seldom seen teams succeed without processes, I have seen numerous teams fail with them. In my mind they are required but they are not sufficient. In the end, competent and courageous leadership will win the day.

I think the reason why many organizations try to use process to dig their way out of problems is because they are black and white tangible items. They might include well defined and documented phase sign-off, detailed schedules and real acceptance criteria. However, if these processes do not have useful content or the leaders do not make timely decisions or allow constant change, then it is easy for the processes to become lip service.

So what makes a good leader? Here are some basics:

• Communication
• Sense of urgency
• Empowerment

See my recent article in Dr. Dobbs about what makes a good manager at http://www.ddj.com/dept/architect/187203587 for more details.

Here are some basics that you might employ to resolve the leadership gaps in your organization:

• Make decisions in a timely fashion
• Assign meeting action items with delivery dates
• Communicate where your team is headed and why on a regular basis
• Measure your progress and make changes where necessary
• Empower your employees (make it clear what they get to do and let them do it)
• Respond to your employees (respond to emails, questions, etc)
• Treat your employees with respect

Don't get me wrong processes are wonderful things but they are tools. Take the time and interest in leading your team and your processes can be an great ally.

More later ...

Ink has power!

Do you ever have people second guess why you defined the content of a release even though they were in approval chain through email? Do you ever have people complain about the quality of a release when they forced you to send it out early after you told them there were issues? Do people forget about the effect of last-minute features they ask you to implement? You may want to consider old-fashioned ink-signature sign-off sheets for the phases of your product lifecycle.

People often forget casual conversations in person or through email but they do not often forget when they are asked to sign a document. The act of signing has power. In a world where misstatements and fraud are more closely scrutinized than ever before with the Sarbanes-Oxley Act, more executives pay attention to what they sign. Even without this government oversight, many people take the time to examine a document which will contain their signature. The same is true with sign-off sheets. Here are the basics:

• Identify the stakeholders (the higher up the better)
• Provide an executive summary with the salient information
• Provide object information
• Hold up progress until you get a signature

One key to the success of a signature process is to identify the people who are the largest stakeholders. In most companies this includes engineering, product management, sales and support. Try to keep the number of people to sign at a minimum but do not scrimp either. Pick executives with the big picture and big responsibilities -- first line managers or even directors are probably not the right level. Figure out some way (faxes work fine) to have the signature process not bog down due to peoples travel or meeting schedules. Provide a meeting time in case the stakeholders want more information about what they are signing.

You must distill the information into easy to understand pieces and consequence. For example "Waived 50% of bugs that are required to be fixed by criteria and this may result in customer failures and reputation issues." Even better if you can color code critical issues with a red background. Provide layers of information attached to the sign-off sheet so that stakeholders can drill down if they wish.

Many times executives ask how people "feel" about a phase or release. I feel this is inappropriate because it is subjective, inaccurate and often causes significant disagreements between groups. Take a look at the criteria section in my book 100 Questions to Ask your Software Organization for more information on how to objectively qualify releases.

Finally stick to your guns. Often the real discussions do not occur until you require real signatures. If you forgo the process, you will be forgoing the real discussions. A great example of this is that sales teams often complain about what goes in or is left out of a release even after product management has collected their input and closed the loop with them. I have had success in getting to the real discussion because the sales vice president will not sign off.

Ink has power and will help your company make better informed decisions.

More later ...

How can you reduce iterations in your integration cycle?

Do you have volatile integration cycles where many of the builds are not even testable? As a result are you wasting QA effort? Do you end up extending your integration cycle or worse yet release product that has not met your quality goals?

This problem is very common. It does not matter what you call the cycle (Alpha, pre-alpha, Beta, etc.), the impact of entering this period with broken software is profound. You may say that is exactly what this period is for and I will respond that I suggest there is a better way.

Today many organizations complete development and handoff their code to QA for test development and testing. QA must test three things: new feature tests, regression tests and system end-to-end tests. New feature tests will test features that are new to this release, regression tests should test the existing functionality and previous bug fixes, and system end-to-end tests include interoperability, configuration, stress and performance testing.

In my experience, most problems arise from new features. This makes sense because this is where the changes are made. It gets worse if a new feature changes underlying infrastructure or affects a broad cross-section of the product. Often teams endure build after build during an integration cycle to overcome the effects of new features and get to the point where they can find out about regression and system end-to-end tests.

So what can you do? The answer is a very simple concept but will take leadership courage to change. The answer is to move new feature testing and bugfixing before the QA handoff. The answer is to actually use your integration period for integration and not unit correctness.

The new feature's tests should be automated and integrated into the regression test suite before QA handoff. In addition any bugs that you fix to release the new feature to customers should be fixed before QA handoff.

The result will be a more effective integration cycle. The result will be a longer development cycle. This may appear as just a longer overall cycle for a release but in my experience it reduces the overall time for a release and insures better quality. It will also reduce frustration of your team in having to integrate a set of partially working new features.

This dovetails nicely into a train release model as well. No new feature can get onto a train unless it has complete automated tests and bugs fixed.

Philosophically this goes back to the definition of done I spoke of in a previous blog (http://heavenstone.typepad.com/heavenstone_inc/2005/10/index.html). It gets the whole team thinking about moving quality earlier into the development cycle. Because it makes completeness more self-contained within a project, this method can help managers work with employees on areas like ownership and accountability.

Try this and watch your teams be more successful.

More later ...

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 ...

How can you create trust between engineering and management?

The software development industry is very much like a dysfunctional family. Executives don't trust that engineering will deliver what they say they will deliver and they don't trust it will be on time. Engineers think that executives set unreasonable goals and don't provide them with the resources to succeed. What can you do to engender trust as a manager?

Here are some basics:

• Be feature agnostic
• Be completely open about schedules
• Give executives some choices
• Provide information early about risks and their mitigation
• Provide non-confrontational opportunities for executives to interact with engineering
• Be responsible

Many engineering managers get very passionate about what should be in the product. Passion is good but you must set a boundary for yourself. It is product management's job to take input from the field, engineering, and competition and set priorities. If you appear in the slightest to be sandbagging or subverting in order to push your own agenda, you will lose trust. If you are objective, it is easier to gain trust.

Give all of your information to anyone who wants to see it including schedules and designs. Hiding information reduces trust. If someone does not like the plans your team has developed, have an open discussion. Get down into details. Remove the mystery. It will be painful at first, but people will gain trust over time. If someone wants to argue about the length of time for a particular item, stand your ground. They hired you for your expertise and if they cannot allow you to do your job, your company will have big issues and trust may not be possible.

Make sure you provide alternatives. Consider the following alternatives:

• Existing resources, normal work schedules
• Existing resources with extra effort
• Extra resources
• Phasing features
• Modified release dates

The point is to not come into your boss and say "This is the only thing we can do". Everyone knows there are always choices. If management knows you have looked at the possibilities, It will build trust and confidence in you and your team.

Make sure you are the one informing your management when there are risks. Do not go in and expose a risk without some plan to mitigate that risk. When your boss hears things about your group from others before they hear it from you, it reduces their trust in you and your team.

If the only time your team interacts with management, is when something is going wrong, then it will be hard for you to trust each other. Find informational, social, research and other reasons to meet and build a relationship between you, your team and the executives.

Finally, try to make sure your team meets it commitments. If they can't, take responsibility and make sure that you and your team are working as hard as possible to make it up.

There is a lot more to this, but the above items are a good start.

More later ...

How Can You Make Your Meetings More Effective?

As an engineer, I hated meetings. They were boring. People used them as opportunities get on their soap boxes. Rarely did anything get accomplished.

How can you make your meeting more effective? Here are some ideas:

• Know what you want to accomplish in a meeting before it starts
• Communicate what the goals are for people before the meeting starts
• Take tangents offline (acknowledge they are good points but discuss them later)
• Assign action items
• Agree on when and how you will follow up
• Document the discussion and action items in writing
• End early

I'll tackle the last point first. A good friend and prior boss of mine, Larry Weber, used to say we would all be more productive if an hour was 40 minutes. We allocate an hour for meetings and often expand the meeting to the time allotted. Often, the most costly resource in a company is compensation so use people's time wisely.

If people do not know what the meeting is about, the meeting may flounder or people will hijack it for their agenda. Decide what it is about and what you want to accomplish before you walk in the door. This does not mean that all meetings need to have hard facts or actions at their heart. It is OK to have a meeting to give people a chance to provide their opinion on a matter. The important point is to acknowledge that and make sure every member at the meeting understands the goals.

Finally, whenever you can you should not leave things ambiguous. If there are task identified as a result of the meeting, you should not leave before you identify owners, specify when the task should be completed and how you will track the task.

If it is your meeting, provide leadership and drive. If it is someone else's meeting do no let them waste your time.

More later ...

Work Harder, Work Smarter, Skip Steps ...

Everywhere I have worked people ask me to have my teams work harder or work smarter. What does this mean and how can you do it?

Unfortunately, we as engineers sometimes translate the orders to work harder or smarter into skipping steps. I have been guilty of it myself. You find a piece of a project that needs to be re-architected in the middle or the end of development and you can face it or pray for a miracle. We have all been there.

However, each time we ignore the correct steps, we pay for it in the end. Either we don't make the dates, burn people out and lose them or incomplete or buggy products to the field.

You should employ smart people and you should employ smart processes. Take the time to do requirements documents, specifications and code reviews. Take the time to get sign-off from all of the stakeholders. Take the time to do it again if things change.

Don't get me wrong, you should challenge your teams to get it right the first and you should challenge them to meet their commitments. You should challenge everyone to act as a team and pitch in when things go wrong. Just don't throw out the baby with the bath water. The fun part of software is coding something and seeing it work. The rest of the stuff I mentioned above is like brushing your teeth or paying taxes. Only your leadership will insure the hard parts get done.

The smartest way to work is to take the time to do good engineering. The effort you and your team will need to employ will differ from project to project and company to company. Take the time to figure out what you need and then help your teams accomplish their tasks and hold them accountable.

More later ...

It's Embarrassing!!!!

We can do better!

Last august Toyota announces a major Prius software bug and recall
Last November Microsoft announce major changes in management and delays in Vista
This March the FBI announces more delay in their $500 million upgrade
This April Microsoft announces more delays in Vista
...

Every company has them. Delays due to engineering schedule slips are common place. Significant Quality issues due to inadequate testing or integration.

I want to acknowledge we are all working on our own stuff. At first glance maybe you should not care if Microsoft has another delay. We are used to it. They are not us. They might even be the enemy and you may take joy from their misplanning. I am here to ask you to reconsider.

Whether you like it or not we are part of an industry. From the Linux developers to Windows developers, from embedded to supercomputer, from Assembly language to business logic we are failing. No one can depend on us. Not our customers. Not our sales people. Not ourselves.

One might say the problems stem from the youth of our industry or the rapidness of change. You might want to blame hungry investors and executives who have become accustomed to setting impossibles goals assuming that no matter what date is set won't be made. Still other might indict the workforce for not being able to plan or not working hard enough.

I will suggest we are all to blame. We can do better. Dogma and standards will not win the day here but results will. I believe there are two things that can make the greatest difference between predictability and the status quo:

• Leadership
• Education

Without leadership from investors, executives and managers nothing will ever change. You have to vote for predictability to make change. You have to know it will take time to achieve. You have to know it will require tough decisions like making priorities.

Without education we will never be better. We have to start training technologist to be leaders in school. We cannot expect them to magically develop those skills in the work force. We have to train engineers before we ask them to be managers.

Dr. Dobbs has just published an article I wrote on some of the things it takes to be a good manager in their June issue. Check it out. It is a good way to start the dialog. Feel free to contact me on how we can start to change the industry (mark@heavenstoneinc.com).

More Later ...

One more feature please ...

How can you get discipline to not have feature creep? How can you decide when it is appropriate to change your plans to accommodate a request? What can you do if your business depends on accommodating feature requests?

In many ways this goes back to the discussion about how important predictability is to your company. As I have said before, I believe it is paramount. It is how your sales folks know what they can sell and how customers can know what to expect and depend on it. Predictability as a priority allows your employees to stay focused and feel accomplished.

Unfortunately, we know the technology world changes quickly. Here are some basics you must do to even have a discussion about change later:

• Have an approved budget
• Have an approved roadmap
• Have a release definition and approval process

Once you have these things, then you can put in an exception or variation process. Without them, your developers and company will experience unpredictability and chaos.

You should develop an exception process that looks at the following:

• The business case for doing the feature
• The development cost for doing a feature
• The other things doing this feature will affect like schedule or resources or customer expectation
• Executive signoff

The major thing is to make a premeditated decision. There are almost always tradeoffs and your company needs good information in order to make those tradeoffs. Good executives will help make sure the right decision is made and minimize the number of exceptions they will entertain.

If you find that you are experiencing a lot of feature requests because of customer requirements or industry requirements, then you may have to firewall resources to handle them. Think top-down. How much of your development resource do you want to dedicate to handling these kind of requests? Allocate them and use managerial courage to not allocate anyone else. If you always dip into all of our resources, you will never accomplish the less tactical and more strategic goals. Get agreement from the stake holders like sales or professional services on the allocation. If this still does not meet the needs of the business, you may have to rethink your business model.

Change is good. Constant change is not.

More later ...

Employee Performance Reviews

You have to do them. You have to do them on time. You have to be honest and constructive.

There are a number of goals for reviews:

• Have better employees
• Make sure employees and managers understand each other's views on the employees performance
• Provide a basis for compensation and promotion purposes

The first goal of having better employees should be your primary goal. This is where you help employees understand areas in which they to improve and this is where you encourage good behavior that you want them to continue. This is where you document issues that may be a basis for managing unproductive employees from your company. This is where you help your company and the universe by telling your employees the truth.

I have had situations where employees have thanked me for being the first person who was honest with them. Some of those employees used these reviews as a turning point in their careers and in their lives.

Here are some basics for reviews:

• Keep reviews concise. It is easy to lose track of what is important in long reviews.
• Use examples. Do not bring up generalities. If you cannot find an example, skip the comment (good or bad).
• Get employee input. It is important to understand and discuss the difference in your perceptions about your employees performance.
• Get outside input. Make sure to understand whether an issue or strength is only recognized by you or is seen by others.
• Make sure that a review is not used as the first time you bring up an issue with an employee. You need to have regular discussions throughout the year.

Take reviews seriously. Remember when you were an individual contributor. Take care in producing them. Respect your employee by completing them on time. Reviews become the basis for discussions about compensation and promotions so they hit your employees in their pocket books. They also become a matter of self-esteem. Do not underestimate their impact.

Do valuable reviews. Make your team better.

More later ...

How do you handle the end-game of a release?

So you did everything right. You defined your product and acceptance criteria well. You focused on the task at hand. You followed good processes for design and development. Now you have hit code complete. How do you get from here to a released product? How do you manage your resources and schedule?

Everyone has their own names for various phases. So that you understand what I am referring to, let's start with some definitions (the following definitions explain what you should have at the end of each phase):

• Development: design, design reviews, coding, code reviews, test code development and test code reviews are complete. The features basically work and the tests have been run but bugs may exist. You have met the Alpha entry acceptance criteria.
• Alpha: All criteria for General availability are met. Ready for field test. Beta documentation is ready.
• Beta: All criteria are met and the product has been field tested.

At the end of Beta, the product is ready for General Availability. Some companies have a Limited Availability phase before General Availability to augment their field test. Many customers will not field test Beta. A Limited Availability Release provides a production product with expectations that the product needs more field exposure.

The aforementioned phases occur regardless of what you plan or what you call them. Some people release final product to the field that I would call Alpha. The product still must go through the rest of the phases to achieve the stability expect in a released product.

Do not enter one phase until you meet the acceptance criteria for the previous phase. If you do, you will just be fooling yourself and slip later on. It is near impossible to make up time during these integration phases.

How do you size the time required for Alpha and Beta? A number of factors should be considered including:

• The number of features added to the product
• The amount of foundational change in a release
• The length of a QA cycle
• Efficiency of the team at addressing issues
• How complete the product is from the previous phase

This paragraph provides some guidelines for scheduling Alpha and Beta. If you have a product that can be robustly tested within a 7 day period and you introduce 10-30 moderate-sized features, then the Alpha time would be from 4-6 weeks and the Beta time would be from 6-8 weeks. For a larger product of 30-100 features, an Alpha cycle of 12 weeks and a Beta cycle of 24 weeks is more appropriate. Clearly the above factors will modify those times.

From here it is a matter of managing the test cycles, field test cycles and the bug list.

You must make sure that your test team has viable test candidates. Try to not sequentialize test (i.e. don't delay doing one test because another did not work). Make sure the test information is clear and concise. Report progress to the whole team. You should consider any bug stopping the test team from doing their testing, as the highest priority bug to fix.

Someone must drive field test. Start it as early as possible (even during Alpha). Make sure you are using your own products where possible. There is no substitute for real world testing. If you cannot accomplish this, you may have to do a limited availability release (see above). Make sure there is enough time to get feedback from the field test and incorporate changes. Send someone to customer sites to get them up and running quickly. Define what you need them to accomplish. Select your Field test sites well. Avoid using pre-sales customers as field test sites.

The final thing is the bug list. You need to agree upfront about what your criteria is. Do not wait until the end to negotiate this. Do not use Alpha or Beta time to fix bugs from the previous releases as they should have been scheduled during the Development phase. All releases have bugs. When you classify bugs, the only piece of information that is important is when the bug needs to be fixed by:

• Development complete
• Alpha Complete
• Beta Complete
• First Patch or Bugfix Release

Your product team including product management, engineering and support should help determine when or if a bug must be fixed.

You need to track the trend for your bugs. The three critical pieces of information are:

• How many bugs can your team fix per day
• How many total bugs are in the system
• How many new bugs your team is finding each day

With this information, you can determine whether you will make the schedule. You can also set goals about where you need to be during each week of Alpha or Beta. The product team can determine the cost/benefit trade-off for fixing each bug. If you cannot make the schedule, then you should ask your team to work nights and weekends to help try and get back on schedule. This is typical and should be expected for the integration phases of a release. If the trend continues, you will need to adjust the schedule to accommodate improving quality and you should examine your development practices so that you can do better on the next release. If you are experiencing a lot of bugs or as you get close to a milestone, conduct daily meetings with your direct reports or full staff as needed.

Once your release is stable enough to reach Beta, you need restrict the type of bugs you allow into a release. You must assume that any bugfix is as likely to introduce a new problem as it is to fix an existing one. You must also provide more restrictions and scrutiny on changes you allow your developers to check-in. More rigorous code reviews and management sign-off is common.

Finally when you reach a point when you have your golden bits that you wish to release, you must have rules about what to do between the time you ok that release and when it gets into customers hands. You will always find one more thing you can fix. So create a rule that says any bug found after the release is signed-off must go into the first patch or bugfix release (unless you would have stopped shipment for the bug in an already released product).

It is easy to slip releases in Alpha and Beta phases. There are always exceptions to the above process but you should remain focused, watch things closely and adapt.

More later ...

How do you address unproductive employees?

I just read an article by Scott Reeves at Forbes on this subject. He made a lot of salient points and the article is worth reading (click here to see article) but he missed a basic point: how do you make employees accountable?

Many employees confuse accountability with micromanagement. As Scott says in his article, micromanagement will never succeed. Employees resent micromanagement. Your team needs to understand that it is you job to produce predictable results. Your team needs to understand it is your job to get measurable status on a regular basis for all employees. Sounds like micromanagement right? Well the difference between accountability and micromanagement is in the process of getting the information and what you do with it.

Here are the signs of a micromanager:

• Ignoring pre-agreed to reporting points and asking status more frequently
• Getting mad at people for missing status
• Constantly changing working assignment
• Dictating implementation instead of requirements

You have to give people a chance to do their job in a positive environment. You need to look at problems as just things to be solved. You need to engender trust so you can get the truth when you ask for status.

Without an environment where there is accountability and trust, you will never help employees improve and you will never manage problem employees out of your organization. Every employee should know what tasks they should be doing. Every employee should know if they can go home at the end of the day or if they need to work harder. Every employee should have a schedule.

Employees should be involved in making their own schedules. Managers need to work with them where appropriate. Some employees are not experienced enough to develop schedules on their own but they should be involved in the process. Dictated dates are artificial and you will not get buy-in. You need employee buy-in to have reasonable accountability.

Once everyone has a schedule, you need to track it. At the beginning of a schedule, weekly meetings can suffice. At the end of a schedule during integration periods, daily meetings are often required. Do not expect everyone to be making their schedules on time.

From here the process of objectively identifying unproductive employees is easy. They are the ones who chronically miss their schedules.

Your number one goal should be to make them productive. Managing employees out and finding new ones to replace them is costly and it is worth some effort to try and turn them around. This requires a positive attitude on both the employee's and manager's part. If this fails, then the accountability based on real schedules will be an important piece of documentation in taking further or final steps. If it reaches this point, you need to follow your company?s policies carefully.

More later ...

How do you develop predictable schedules?

Let's go back to basics. I believe predictability is the main reason to have schedules in the first place (see my earlier post on schedules). The only way to get predictable schedules is to pick good tasks. So how do you pick good tasks?

Here are the basics on how to do it:

• Pick tasks of reasonable size (10 days maximum)
• Make sure the result is measurable
• Legitimize design time, test development time, integration time, etc.

If the duration for your tasks are too long, then you will not know your task is running late until it is too late. Slips in long tasks cause slips in releases. The only way to mitigate this risk is creating smaller tasks. This may require more scaffolding to test intermediate results. It may require longer schedules. If your goal is predictability, you need to tell your team that predictability is a priority for you and it is ok to identify shorter tasks, even if it results in a longer schedule. Longer schedules alone will not provide predictability. You need smaller deliverables.

Each task should have a measurable deliverable. Without a measurable deliverable, the schedule and the task are meaningless with respect to predictability. It is easy to create a task whose description is "Coded new APIs" but at the end what do you have? All you have is that code. Does it tell you that you are finished? Does it tell you it works? What if someone finishes the coding but it takes twice as long to get working? Identifying a separate integration phase does not help either because you cannot tell how far along you are. Instead I suggest a task description like "coded, developed tests, code reviewed and checked in 5 APIs". If the original goal had 15 APIs, then I would create three of these tasks (or whatever fits in 10 days). This sends a clear message that the task isn't done until it includes all of its pieces and is measured.

Finally, make sure that tasks include explicit time for design, code review, etc. It is easy to either slip because of these items or worse skip them. They are not the most fun tasks for engineers, so make them count. Without these items, it is easy to slip a schedule late in the game because of a lapse in up-front hygiene.

This is hard and your teams will need both practice and help to succeed, but it will payoff in success and rewards.

More later ...

How can you create urgency in the hiring process?

Have you had outstanding positions that have gone unfilled for long periods of time? Are qualified candidates going elsewhere?

The first thing you need to do is make hiring a priority. Next to budget planning (i.e. getting money to hire), hiring should be the next most important thing your team does. Without people, you cannot accomplish your goals.

Your team needs to understand they can, if necessary, slip other things to support the hiring process. Until they do and until you actually support that ideal, hiring will always remain secondary. It is much easier for your managers to spend time on fighting fires or working on products than hiring.

The second thing I would do is set goals for your team and hold people accountable. Here are some sample goals:

• Resumes reviewed per position per week
• Hires per month per manager (goal: 1)
• Time elapsed between identifying a good resume and a phone screen (goal: 48 hours)
• Time elapsed between a good phone screen and face to face interviews (goal: 48 hours)
• Time elapsed between good face to face interviews and an offer (goal: 48 hours)

Time allowed for candidates to accept an offer (goal: 72 hours)

Set goals for the above items with your team. I have place some goals I have used before in parenthesis above.

Another big issue that limits hiring is that many companies allow teams to have way too many people interviewing a candidate. I limit the number of interviewers to 4. Pick people you trust to do the interviews. Make it a priority for them to interview candidates. Make sure you get their input back quickly. You can support senior candidates who want to talk with more of the team but make sure to set your team's expectations.

Many companies are pennywise and pound foolish. They will negotiate every little piece of compensation to get someone at the lowest cost. In the end, you may leave a bad taste in a candidate's mouth. Even if they hire on, they may resent the process. It also takes a lot of time in the process. And, in the end, it costs much more if you lose a candidate.

So with all these techniques to increase urgency, how do you make sure you are hiring good people:

• Learn which members of your team are good interviewers
• Do reference checks (blind ones too if you can)
• Train and manage new employees well
• Don't be afraid to manage out mistakes quickly
• You can make a positive difference in how your team hires!

More later ...

What are the key factors in good morale?

In my job as a management consultant, I get asked to lead teams that have been through some amount of trauma including management changes, layoffs, missed schedules, etc. I am always asked about their morale and what we can do to improve it. The following is a list of basics:

• Improved sales
• Having a job
• Interesting work
• Communication
• Accomplishable tasks

There is nothing that helps morale more than a company that is doing well. Everyone wants to be on a winning team! If employees can see path to continued employment, R&D expansion and increased remuneration (stock and/or salary) then that is a great incentive. Note that success can be a two way street because there is a natural ebb and flow of employee movement. If a company is doing real well it is unlikely that movement will occur and it will take closer management of your employees to make sure people are not just hanging on.

Following 9/11, many developers were laid-off one or more times. Developers took lower salaries just to have a job. For many engineers this was the first time in their careers that they were out of work for any substantial amount of time. Stability rose as a priority in job seekers. While the environment has gotten brighter recently, the memory has not been forgotten.

Engineers may go to a company or stay at a company for the quality of work. The art and science inspire and compel many high-skilled developers to join or stay with employers. If all you have is maintenance work for your employees, do not assume they will stay even if you incent them. Incentives (bonuses, increased salaries) work for a while but not in the long run.

Employees can put up with a lot of hardship and change if they feel they are part of a team. The first way to make them feel like they are part of a team is to let them know what and why things are happening in a company. Communicate often and make it two-way communication. Solicit employee ideas. Explain rationale. The more you can share the better. Make sure you have a plan or a plan for a plan when you talk to employees -- ambiguity does not inspire confidence.

Finally, the item that is the lynch pin in morale, success, and satisfaction: accomplishment. If employees have impossible goals and they can never make those goals, they will always feel like failures. All good things in a company stem from accomplishment. If engineers can accomplish their tasks, sales has a chance to sell product, the company has a chance to make profit, employees get to make some money and do new exciting work. It ties it all together and it just feels good to accomplish something!

Go out and accomplish something with your team!

More later ...