Archive for November, 2009

How do you retain best people? Answer – how you recruit

November 26, 2009 1 comment

The extent of present economic difficulties have not been seen for a long time.

If you are a software executive with a responsibility to recruit, retain, and lead a team of dedicated people …

– Try to take a pause and ask whether your organization is at risk

– Chances are everyone has to work much harder because the team is smaller

– Some are quietly asking whether all this work is worth it but choose to stay because there are no other opportunities available

– Don’t wait; this is the time to reconnect with everyone again and learn what’s on their mind

The economy will recover.  When it does, the wave of great people (the one’s you want to keep) choosing to leave instead will be unprecedented.

Retention of great people starts with how one recruits.    Despite how memorable the last difficult day at work may be, the most memorable and lasting impression is created by the recruiting process.

Several years ago, I extended an offer to a brilliant software engineer who after 4 phone screens and 2 in-person interviews declined the offer.   I was shocked and called “N” at 8:00pm with an advance apology for disturbing the family dinner.

“N” told me that it was a very difficult decision to say no to a financially attractive offer.  “N” wanted to work in my organization after meeting with me twice.

“So – what happened?”, I asked.

“N” told me that every person in my organization assigned to conduct phone screens did not call on time.   One phone screen, scheduled to start at 10:00am, did not begin until 10:30am.  Another phone screen, scheduled to start at 8:00pm, did not begin until 9:00pm.   The third person did not call on time because of a meeting that never seemed to end.    The fourth and final person was so distracted by e-mail traffic during the phone interview that the candidate was wondering whether this was a good use of everyone’s time.

I listened and thanked “N” for providing me with an honest feedback.

“N” was right in declining the offer.  The organization completely failed to:

– Show the candidate that “N” was 100% important to the organization even as a prospective employee

– Use the recruiting process to create a lasting impression, “This is how we recruit.  Imagine how we take care of our people once you join the team”.

Of course, what happened with candidate “N” never happened again – ever.

Fortunately, there were two other candidates being actively recruited.  Candidate “G” was hired.  Candidate “O” did not receive an offer.  Yet, “O”was so impressed with the recruiting process that – despite not getting an offer –  “O” cheerfully recommended someone who was eventually hired.

The way one retains is the way one recruits.   In today’s economy, this could not be more relevant.

Categories: Hiring, The economy

Why it’s good to be paranoid if you are a product management executive

November 24, 2009 Leave a comment

One of my all-time favorite books is “Only the Paranoid Survive” by Andy Grove, former chairman and CEO of Intel Corporation.

In early 1980’s, Intel’s business was driven by DRAM chips.   Andy Grove saw the potential in microprocessors and the rest is history, including a complete transformation of Intel’s business model and product strategy.

It’s good to be paranoid if you are a product management executive and have early visibility to indicators that may compel the company to change its product strategy.

At the same time, it’s also good to ask a very basic question before the company is facing a competitive threat.   What kind of change is the company capable of?  Complete transformation – if needed – or incremental change that may not be good enough to face a competitive threat?

Even an incremental change in a product strategy will require re-alignment of product marketing, sales, engineering, and professional services organizational resources.  There will be many late nights chaired by the CFO reviewing and comparing different revenue forecasts and P&L scenarios.

Significant product strategy change will challenge every thread in the organization, from executives to every employee  – regardless of their role or experience.

The inconvenient truth:  very few companies are capable of significant product strategy change unless there is a conscious and deliberate effort to build a culture that can be capable of great leaps … well in advance.

Go beyond the basics of normal paranoia when leading a product management organization in a software company.  Be paranoid about the ability to change and respond first.   There are plenty of product strategy presentations collecting dust as an outcome of being unable to execute.

Categories: Product Management

Two perfect software engineering candidates: how do you choose?

November 18, 2009 Leave a comment

After a significant investment of time in the recruiting process, it’s a wonderful problem to have two perfect software engineering candidates.

Both candidates have deep experience in required technologies and demonstrated passion about developing great software products.   Plus – the software engineering team liked both during the interview process.

How do you choose one of them, even if a background thought continues to remind you that perhaps hiring both may be a good idea?

I learned over the years that one’s willingness to find a way to delight the customer in any situation – even if the product generates an error – is one of those defining elements that can make one perfect candidate seem even more perfect.

It’s a lot easier to delight the customer by delivering required functionality.   All is well when the software works as expected.

However, what happens when the customer begins to experience unexpected errors, confusing error messages, and lack of logging or diagnostic features?  Customer’s confidence in the software can be quickly eroded.

The truth:  the opportunity to delight the customer when the software does not work as expected is greater than when the product works as expected.

Although no one likes errors and unexpected functional behavior, the customer’s confidence in the software will actually increase when the software handles errors with grace and precision, while providing appropriate level of feedback to the customer.

So – how did I choose between two perfect candidates?

I asked both to consider the following scenario:

– “You are starting next Monday”

– “The product you just inherited does not contain a single error message or a message of any kind”

– “Think about an approach to begin introducing messages in the product – informational, errors, exceptions, or whatever you think may be required”

– “Let’s discuss your ideas in 10 minutes”

The first candidate struggled with the scenario.   “J” continued to look for a specific technology approach and – when faced with uncertainty – went back to a comfort zone of knowing how to use a well-known logging framework.

The second candidate got it right. “G” asked me a lot of questions about product architecture, user experience, critical functional paths, known defects, priority of defects, specific customers experiencing defects (who was more vocal).  “G” even asked which customers were at risk of not renewing the software maintenance contract. Then, “G” wanted to prioritize critical functional paths and correlate high priority defects.   “G” talked about order management process and the majority of defects that occurred after the order was submitted.  “G” also wanted to learn if certain defects were clustered in certain sections of code.   ‘In addition, G” thought it would be a good idea to address these defects with “one surgery” and localize changes in one or few related components.

It became very clear who turned out to be a perfect candidate.




Categories: Error Management, Hiring

Who will buy enterprise software (or the next bubble)

November 17, 2009 Leave a comment

It’s tough to build enterprise software.  It’s even more difficult to sell it.  Enterprise software runs the business of many companies and the buyers are very demanding and diligent in their evaluation efforts.

But what if the corporate community of enterprise software buyers cannot buy the software because their financial performance does not allow them to think beyond immediate cost-cutting measures?

No one wants to see another bubble to burst in the fragile fabric of US economy.  Yet it’s prudent to ask whether another bubble could be around the corner.

This November 15, 2009 news article from New York Post (The Next Bubble:  Spike in PE-owned firm defaults ahead) was very troubling.  According to the article:

“In December 2008, the Boston Consulting Group, which advises PE firms, predicted that almost 50 percent of PE-owned companies would probably default on their debt by the end of 2011. It also believed there would be significant restructuring at these companies, leading to massive cost cuts and difficult layoffs.

A rain of defaults is already starting. From January 1 through October 31, 2009, 175 American companies defaulted on their debt. That is almost double the number for all of 2008. Half of those companies have been involved in transactions with PE firms at some point in their corporate life, according to the Standard & Poor’s rating agency.”

American software industry is the leader in innovation which fuels traditional and new business models.   I hope future enterprise software buyers will still have the budgets to buy the right solution to help them grow and expand.

Good questions that software engineers (for a change) can ask prospective employers

November 15, 2009 2 comments

It’s difficult to hire great talent, especially for an enterprise software company.   To build a product that ‘sells itself’ (a topic I will cover in a later blog entry) one needs to find, attract, hire, and retain exceptional software engineers.

Some time ago, I had one of the most satisfying discussions with a senior software engineering candidate.   The interview process was very intense: 2 separate days, 6 personal interviews with different members of the team, and then a three-hour long design session with the same 6 individuals (yes, every white board was fully covered with diagrams at the end ).

The engineering team wasn’t very excited about “Jane”.  Some answers were not particularly deep.  But – everyone agreed that “Jane”s” problem solving skills were first rate.  In one problem solving exercise, “Jane” was able to come up with an elegant design approach with a promise to reduce development time by more than 25%.   When faced with multiple counter arguments, “Jane” successfully justified the proposed design approach.

I always reserve at least one hour for every candidate to have enough time to ask any questions about the company, customers, products (current and planned), team, etc.

“Jane” was well prepared and asked a number of great questions.   I thought these questions were a direct indicator of “Jane” being the right candidate.  “Jane” cared deeply about the business of delivering great software, not just the job itself.

About the company:

– Please tell me about company’s financial performance:  this year vs last year?

– Which products contributed to the revenue growth?

– What are the major competitors?  How would you compare your products to the competitors’ products?

About the customers:

– What customers love your software and why?

– What customers are not happy with your software and why?

– What do you think needs to be done to make these customers happy:  add requested functionality, correct existing functionality, improve quality?

– What are the top 3 features requested by the sales team?  Is the sales team happy with the speed of delivery?

– Did you lose any customers?  If yes – why?  What are the lessons learned?

About the software product or products:

– What releases are planned in the next 12 months?  What functionality will these releases delivery?

– If I had to work on any new feature, what would it be?  Why?

– How would you rate the strength of product management process?  Will I get clear specifications or – when needed  – a fast response from product managers?

About the team:

– What advice would you give me as a new employee to become a productive member of the team as soon as possible?

– Who do I need to meet in the first 60 – 90 days?  What are their roles?

“Jane” turned out to be one of the best hires.

Categories: Hiring

Part 2: Identify critical design elements – early

November 10, 2009 Leave a comment


That’s the word that comes to mind after a very long (and at times very vocal) design session that ultimately led to good design decisions.

Why was the decibel level a little higher than normal?

The current design was based on the aggregate ‘weight’ of over 500 functional requirements, to be delivered in 6 major releases.  There were additional 300+ requirements in the pipeline but were not yet discussed in detail.  Also – the current design already had a number of known items that concerned everyone in the engineering team.

The team faced a decision point:  do we invest time and try to understand if future 300+ requirements may substantially influence current design?   The upside – the design will accommodate future requirements and reduce the risk of refactoring.  The downside – missing time with the families …

It turned out that some future requirements indeed had a significant impact on the current design.   In fact, had the team decided to develop the next 6 major releases based on known 500+ requirements, at some point the probability to completely redesign several critical components would be 100%.  Even more time would have to be spent with fellow colleagues and not families in this case.

The breakthrough was achieved by going back to an example that I used in the past to illustrate how important it is to identify critical design elements as early as possible, even at the cost spending a little more time upfront.

Let’s assume there are separate design teams working on these 2 problems:

A. Fly from New York to Paris in 3.5 hours

B. Fly tom New York to Paris in 8 hours

The design for Option A would yield an aircraft that looks like a Concorde, while the design for Option B would produce a Boeing 767-300ER (or equivalent). These aircraft could not be more different.

Just imagine if by some sheer chance the team pursued Option B (or Boeing 767-300ER) design as an option to fly from New York to Paris in 3.5 hours. It’s impossible for Boeing 767-300ER to accomplish this because of several intentional design decisions made very early in the process: choice of engines, alloys, wing geometry, etc. This is not intended to be a lesson in aircraft engineering but I hope the message emerges.

This example is particularly helpful as an illustration of potential risks: Boeing 767-300ER can never become a Concorde. If the software had fundamental design constraints, these constraints cannot be refactored. Only a new design can solve these problems and making a commitment to a new design is expensive, time-consuming, and at times necessary. But – if this commitment has to be made, going back to the fundamentals of good software design is step one.

Identify critical design elements as early as possible, even if the requirements are not well known. Make the design sustainable over time. Test the design assumptions against known and likely requirements, even if these have to be delivered 12-18 months from now.

It’s always good idea to separate needs from requirements

November 6, 2009 4 comments

Anyone who spent enough time building complex software products will probably agree that – when it comes to design – hindsight is truly 20/20.

There are many definitions of a good software design.  Regardless of the definition …

– Good software design always tries to balance known as well as potential requirements

– Good software design creates a stable platform to accommodate multiple major releases without the need to significantly change the underlying architecture

Why is it important to separate needs from requirements when evaluating essential elements of a good design?   Perhaps needs and requirements are the same?  They are not – and it’s good to introduce very basic definitions for both.

– Needs are specific business outcomes the customer needs to achieve in the business by using your software.  Needs are “ability to pay invoices online”, “ability to accept credit cards online”, etc.

– Requirements are – simply put – the functionality in the software product that must exist to support customer needs.

There is a very important cycle that cannot be ignored when designing software products.

Needs -> influence -> requirements -> influence -> design

Let’s illustrate why this so important.

– The customer expresses a need to have invoices paid online.  The requirements can include: supporting 100,000 users vs supporting 1,000 users, downloading invoices, viewing invoices on one or more mobile device types, different security / authentication mechanisms … and the list goes on.    By exploring & validating requirements as they match customer need, only then one can begin to accumulate raw materials for subsequent design consideration.

– Some customers will want to see all requirements mentioned above

– Good, anticipatory design will accommodate these requirements (in future product release over time) while preventing unplanned refactoring efforts.

Refactoring is a very costly effort which carries many risks, including higher defect rates and delayed software releases.  In a highly competitive market, unsuccessful refactoring efforts can have significant negative effect on the bottom line of the software company.