The best predictor of success in a new hire is not industry knowledge

Great recruiters are even more rare than great candidates.

Even before beginning the search for talent, a great recruiter will learn everything about your business:  mission, stage of growth, competition, culture, organization (how it looks today, how it may look tomorrow), and then will spare no effort to find superb talent that will play a critical role in creating the next generation of software products.

I have been fortunate to know a truly great recruiter for a long time.  ”J” consistently found senior software engineers, software design engineers in test, product managers, and product marketing managers who proved to be very successful.

Is there a single, best predictor of success in a new hire?  That’s the question “J” asked me last week.

It is not industry domain knowledge, although it’s important in many cases.

It is not experience, although – again – experience provides good insight about candidate’s past performance.

The single, best predictor of future success is a relentless desire to learn.   This desire has to be overwhelming, overflowing – “always on” – and humble enough to share knowledge with others without even thinking about it.

So why is this true?

Some time ago, I was asked to lead a new product development effort and deliver an enterprise software product  …

- which never existed before

- was intended for a new market (in essence – this product was intended to create a market)

One of the immediate goals was to recruit a software engineering team, capable of solving very complex problems while building a software product without known competitive references or prior experience.

First – let’s examine a typical job posting:

“Financial services company is looking for a superstar Java software engineer [technology keywords and acronyms follow].  Superb communication skills are mandatory.  Local candidates only.  Financial services experience is a must”.

The above job posting would not produce even one candidate.  The market is new.  No one else built a similar product.   Every candidate – if hired – will be placed in a difficult and stressful situation:  learn new industry, learn what the customers want, and apply creative energy to solve complex problems in an environment where failure is not an option.

Different recruiting approach had to be used.  ”J” and I crafted job postings which – by design – attracted candidates with skills, experience, and – most importantly – that relentless desire to learn.  Without this desire, skills and experience – no matter how deep – would not be of any help.

In summary, great talent does not always come from the same industry domain, just like great talent may not be next door.

For those who are interested in more information:

- The company:  www.mediasolvcorp.com

- The market:  integrated digital evidence management software for law enforcement agencies (secure acquisition, management, and delivery of audio, video, images, and documents)

- Why: as of September 2009, 17 states and District of Columbia require electronic recordings of interrogations

- Market potential:  big – others certainly think so:  read about TASER “entering the data business” with EVIDENCE.com

You just arrived as a new CTO; step one – get on the road

After a long and diligent recruiting cycle, you just arrived as a new CTO in an enterprise software company to lead both product management and software engineering activities.   What you will do in the first 2 weeks will be critical to your success.

Not all is well.  Revenues are flat.  Some large customers are at risk of not renewing their maintenance (or subscription) contracts.   The latest and long-awaited major release has been delayed.   The sales team also lost some sales superstars to competitors.

Try to make the first day a Friday.   You will need the entire next and your first week for a very specific purpose.

Friday:

- In the morning, meet with your direct reports, take them out to lunch, and apologize for not having any time for anyone during the first 2 weeks

- In the afternoon, meet with VP of Sales & Marketing and learn everything about revenues and customers

- Identify critical customers and ask VP of Sales & Marketing to make phone introductions.  Resist every attempt to have the sales person accompany you.  You want to send a polite message that your purpose is to listen, not sell.

Sunday:

- Get on the plane and travel to the first customer on your list

Monday – Friday, while meeting with selected customers:

- Learn everything about how the customers use the company’s products in their environment

- Get a list of critical bugs and defects

- Measure the flight risk – whether the customer may defect to a competitor

- Ask how the entire company – not just engineering team – serves the customer:   sales, professional services, customer support, training.  That’s the reason why you want to be alone while listening.    As a CTO you may build a great product but the professional services organization may not deploy the software correctly, creating an opportunity for competition.   Start collecting insights and real, unabridged feedback from the customer.

Monday (your second week):

- Meet with VP of Sales & Marketing to review the sales pipeline.   Get ahead of the business and critical ‘must close’ deals.

Tuesday:

- Meet with the owner of customer support organization.  This organization should have the same sense of urgency that you gained when meeting with customers last week.

Wednesday:

- Meet with the owner of professional services organization.   Again – the product deployment process should delight the customer.  Anything less?  Take notes.

Thursday:

- Meet with the CFO.   Learn the budget history and current budget metrics.

Friday:

- You are now well equipped to meet with your direct reports.

There is a reason why the new CTO should meet with his / her organization last.   You want to know as soon as possible if the organization is capable of meeting the demands of the business.   That’s why you spent the first 2 weeks:

- Getting the unabridged version of state of the business from real customers

- Learning how other organizations (customer support, professional services) serve the customer;  you cannot succeed alone

- Learning how much financial flexibility you have to address any problem

Finally, you are ready to learn if your organization can embark on the journey together with you.

It turns out great talent is not always next door

Recruiting, attracting, and retaining great talent continues to be one of the biggest challenges facing a software executive.

It’s truly a privilege to work with great people.   They are the reason why in a competitive market one software product can be easily seen as one that sells itself – with assistance from a terrific sales team, of course.

But even great people can leave the organization for many reasons, creating a continuous need to recruit and retain.

While growing several world-class engineering organizations, I learned several truths about recruiting great talent:

- The way one recruits says a lot about how one retains

- Never stop recruiting, despite no openings being available;  it takes at least 3 months to find someone exceptional

- Forget gold; treat every candidate like platinum;  make the decision not to extend the offer so incredibly graceful that the candidate will still recommend his / her friends (“I feel bad about not getting the offer, but my friend who is looking for work will feel right at home in this fantastic company”)

- Make the recruiting process very rigorous (yet very respectful);  candidates may feel exhausted but the right ones will respect it (“I want to be a part of this great team”)

- 100 good resumes will typically yield 4-7 great candidates;  to have the luxury of 100 good resumes, the talent sourcing process needs to be flexible and sufficiently broad

That’s where the final truth could not be more appropriate.

- Great talent is not always next door

Many companies are very reluctant to consider candidates that live outside the immediate geography.  In fact, many companies simply ignore resumes from out-of-town candidates and clearly state ‘local candidates preferred’ policy.

I was very fortunate to find exceptional software engineers (with help from equally exceptional recruiters) who wanted to relocate to a specific city due to personal reasons, for example moving closer to parents who could help with child care needs.   In multiple instances, a reasonable sign on bonus to cover basic moving expenses served as a very inexpensive method to attract an exceptional person to the team.   Sadly, a standard recruiting process would normally ignore these candidates.

My recruiting team worked very hard.  It was not easy to find these candidates but the outcome produced a candidate who was both eager to contribute and appreciated the investment made by the organization to attract and retain him / her.

Great talent does not live next door.   Never settle and keep searching.  Geography should never be a barrier to finding and attracting great talent.

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

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.

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

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.

Two perfect software engineering candidates: how do you choose?

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.

 

 

 

Who will buy enterprise software (or the next bubble)

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

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.

Part 2: Identify critical design elements – early

Breakthrough.

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

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.