The following describes my professional beliefs, strategies, and philosophies in a way that my resume cannot. Your additions, questions, comments, flames, and feedback are all welcome.

Thanks -- David Henke

One of my former bosses used to say: "No organization works. Any change in the organization is good." While I don’t subscribe to this, I do understand his frustration. Many companies change the organization to simply shake things up, often making things worse, without attacking the underlying problems. Here is the organization that works best for me. Product teams with product champions and individual leaders provide the focus and accountability that are required to act swiftly and accurately. I am not a fan of matrix organizations. Since SGI was (is) an engineering-driven company, engineering management was responsible for far more than product development. We lined up marketing, sales, QA, tech writing, customer support, and build/release, in addition to developing the products. We also had budget responsibility.

While the Engineering Manager is not necessarily best qualified for this job, I believe ONE person should be responsible and held accountable.

There is a need for rigor when building software products, and now, an even greater demand on Web Applications, which are exploding in complexity by contributor, content type, content volume, and turnaround of changes. I have a track record of building very strong QA and customer support organizations, in addition to building strong engineering organizations. I introduced first class software tools to SGI to help with quality issues. I also have a strong belief in version control/configuration management tools, and effective build, test, and release processes.

Still, customers care about end products, NOT processes, which if left to their own device can become bureaucracies. Investment in tools and processes results in quality products and reduction in overall costs.

More exposed in a startup, this has always been the biggest problem for all software organizations. Predictability is based on what I call the "diamond model". You must do top-down and bottom-up planning and development at the same time. Engineers tend to be narrow in focus and overly optimistic. Management tends to be broad in focus and ALSO optimistic. My job is to make sure the expectations of engineering and senior management meet at the vertices of the diamond. I am aggressive, but pragmatic. I do not like missing deadlines that we have all agreed to. In many cases, this is NOT an option (e.g., publishing daily to the Web).

I am a proponent of "time-based scheduling". This works as follows:

• Determine the feature set
• Prioritize the list
• Decide what features must be included for a useful and compelling product (critical mass)
• Draw the line
• Hit that milestone (release 1.0)
• Never sacrifice quality or schedule.
• If you have time for additional features without sacrificing quality, add them to the first release. If not postpone them to the next release.
• Revisit the feature list. Markets and customer expectations may have changed
• Schedule subsequent releases by adding the most important features without sacrificing quality.

One question I ask my engineering manager candidates is, "Quality, schedule, features: pick only two."

There is usually only one right answer to this question.

An old QA maxim is "What gets measured gets fixed." I believe in metrics as a tool for pointing out problems to be fixed, whether they are performance, quality, productivity, or other issues. However, the result of much investigation into software metrics came up with the following rule, "There is NO substitute for hiring the best people." That is, the quality of your team will always be the best measure of what and when you can deliver.

Product quality is very important to me personally. At SGI we were responsible for bringing some of the best development tools to SGI developers, including Purify from Pure Software. We also demonstrated, by example, how regression testing systems could improve the quality of critical products, building a 10000 test Java compiler regression test environment that could be run for multiple operating systems, architectures (chips), and computers, simultaneously every night.

Performance testing is as critical as functional testing.

Quality does not appear to be a strength of many of the Internet/Web companies. Time-to-market pressures, the Internet land-grab for eyeballs, the have-to release today mentality, and the varying levels of customer expectation make quality levels difficult to sustain. I want what the customers want, typically an experience that is useful, fast, reliable, accurate, easy to use, and fun. Successful Internet/Web companies going forward must improve quality levels and user experiences.

I believe one of the greatest measures of a good manager is who they recruit and what impact their recruits have on the company. I am proud of my track record as a recruiter, for both engineers and engineering management. Engineers like to work in a well-run organization and look for managers who execute.

One of the main reasons I remained at SGI for 8 years was the engineering talent level, which I have never seen reproduced in any other company. My recruiting philosophy revolves around simple strategies:

• Hire the best people. Very often, one person does the job of three.
• They will, in turn, bring other good people into the company.
• I prefer the "tall thin employee". That is, find people who can solve more than one problem. Unless I am hiring for a specialty (e.g., database, debugger), I like people with breadth. We may get asked to change directions and our response time may be the key.
• Avoid troublemakers. Most problems are complex enough that they require teams to solve them. As good as some people seem to be, the downside of their negativity is not worth the up side of their brilliance. Every championship sports team wins with superstars (scorers) and role-players (defenders, rebounders). Championship product teams are no different.
• Check unsolicited references. A bad hire can be a large drain on your time, and your company’s resources.

Many newer companies are just now being faced with the difficult problem of maintaining existing products while trying to build the next generation solutions. In Web companies this maintenance is really an ongoing effort compressed into daily cycles instead of the traditional longer software cycle. Several problems need to be addressed:

• Do you have the staff to adequately address maintenance and new development?
• Who gets to work on the next generation products (everyone wants to)?

In a growing organization, this can be addressed by partnering new recruits with seasoned mentors. In my startups, I did not allow new software engineers to author a single line of new code without first working in the customer support, QA/testing, and then maintenance programming organizations (fixing other people’s bugs). This forced them to deal with REAL customers, test other people’s solutions, and fix other programmer’s mistakes. By the time my new recruits did development work for me, they understood the importance of developing quality solutions that satisfied customer needs.

I look forward to working with strong marketing individuals who can represent the customer’s needs and help formulate the products. Believe it or not, engineers really want this!

For many Web/Internet companies moving at break-neck speeds, understanding and responding to the changing market conditions are the keys to success. Engineers want to win, just like everyone else.

I believe in long term vision/direction, and short--term execution and milestones. Everything we do should be in line with the company’s vision.

Every engineer should believe their work is critical to the company’s success and future growth.

At the same time, we need achievable milestones and goals that satisfy customer needs today, and be nimble enough to change to meet unforeseen needs in the future.

I also believe that engineers should have direct contact with the customer base where appropriate. This not only allows them to understand the customer’s needs, it also gives them FIRST HAND understanding of what the products they are building do and DO NOT do from the customer’s perspective. I am always amazed at how many engineers have NEVER talked to a customer

In most interviews, you will get asked, "What is your greatest weakness".

I have been known to "speak my mind" and can be blunt. I am not particularly savvy when it comes to the politics of the company. Some believe this is a disadvantage. I prefer to work for and with those who see this as an advantage.

Some believe there are two basic styles of management, hands-on OR delegation. I believe in the genius of the AND, that is both.

With hands-on management I understand the products, schedules, and know what "everyone" is working on. I also like to test the products personally (the developers like this as well). I realize that as the organization grows, this gets harder to do.

I also believe in delegation and empowerment of my management and engineers. I want them to make hard decisions. There is a keen balance between delegation and decision-making. Knowing when to step-in, and when to step-back is very important.

Key decisions should be made in a timely manner. This is what frustrates me the most in larger companies. In our startups, anyone could call a meeting to discuss any issue. Sometimes the problem was solved in 5 minutes. Sometimes we stayed until 2 in the morning to revolve the problem, or at least to reach an agreement on how to proceed. We all slept better at night.

Communication to and from the team is imperative. They must know what the company is doing, and how their effort will further the company’s success. They must also be heard. Most of the great ideas trickle up, not down. This can be accomplished with face-to-face meetings, whether they are an all-hands presentation, project meetings, or one-on-ones. In turnaround situations it is imperative to talk to as many people as soon as possible.

That said, actions speak louder than words, and engineers look to their leaders for what they do more than what they say. Commitment is shown by example, and employees take cues from their leaders. I stand by my track record with the engineering groups I have managed. I execute. Very often, the team is looking simply for direction and a decision, ANY decision, even if it goes against their wishes. Good leadership is probably the most important management skill that any manager can offer.

At SGI, we basically were trained "by fire". That is, throw the new employee into his/her office, have them set up their machine, and figure out what they were supposed to do. The strong survive, the weak perish.

I do not subscribe to this model. Every new employee in my organization was given a mentor. Less-experienced people were teamed with more senior people. The faster a new employee could be productive, the better off he/she was, I was, and SGI was.

One criticism of my management over the years was my lack of support for ongoing training for my engineers. I took this criticism very seriously, organizing new training courses (especially when we moved from UNIX to Windows), and supporting training for all employees balanced against the particular demands and deadlines of the job. In our business, we must constantly learn new things, and we must provide the time in the schedules to do so.

I ran a customer support organization on three basic principals:

• The customer is a liar.
• The customer is always right.
• Get back to the customer within 24 hours.

Let me explain the apparent contradiction of 1 and 2.

The customer rarely tells you the entire truth about any problem, whether it is describing the outcome or the steps for reproducing the problem. If you can keep this in the back of your mind, and keep a positive outlook towards the actual customer (who is always right), you will succeed.

Also, I like all my employees to have customer contact where possible and prudent. One of my debugger engineers said his entire outlook on product development changed after spending a week onsite with an irate customer. Product decisions, implementations, and testing all are changed with this new outlook.