Archive for the ‘Hiring’ Category

The war for talent: what to ask in the final battle before making an offer

March 17, 2013 1 comment

The commonly described Dot Com Bubble finally burst in late 1990’s.

One of the unintended consequences of this inevitable milestone was the beginning of a talent shortage.    I was fairly certain that in 10 years the talent shortage would be apparent.   I was wrong.   The talent shortage is now more severe than ever.

How did the talent shortage become so severe?

– The recession which followed caused many great software engineers to leave the industry or become underemployed long enough to be considered no longer top talent

– Many companies aggressively shifted software engineering activities to lower cost countries, leading to (and this is the real reason why we find ourselves in this position …)

– Amazing problems solvers with a passion to build something new and exciting decided to bypass software engineering and elected to pursue other professions.   Why become a software engineer if my favorite company where I’d like to work is in the news shifting great jobs (out of sheer necessity to survive, however …) to another country?

Those who remained in software engineering and continued to advance their craft became the smaller community of talent that is subject to many discussions at the present time, or “the war for talent”.

Glenn Kelman, the CEO of Redfin could not have described the war for talent in his recent blog entry, titled “Searching for Beasts in Silicon Valley’s War for Talent”.

Jeff Bezos, the CEO of Amazon, once said (and it became one of my favorite quotes), “You earn your reputation by trying to do hard things well”.

Returning to Glenn Kelman, when evaluating a new hire the question Glenn wants answered is, “When did he / she do something hard?”.

Before making an offer to a great candidate, learning how he / she succeeded while attempting to do something very difficult will be perhaps the best indicator if the offer should be extended.

Some of my best hires emerged from a conversation during an interview where I described a problem impossible to solve in 2 hours and nevertheless asked the candidate to begin thinking about the solution together with me.    These hires all exhibited the basic traits of a great hire:  tough, resourceful, and relentless problem solvers.


Two perfect offers: how do you choose or why organizational courage matters

February 9, 2013 1 comment

Your colleagues call you the very best software engineer they ever worked with.  Your relationship with the current manager could not be better.   But you are not growing as a professional, or perhaps the reasons why you want to explore new opportunities are simply private.

The interviews have been exhaustive but every company you spoke with is very interested in extending an offer.

Yet you are patient, because finding the right opportunity, the one that will proper your career forward, remains the most important goal.

Two companies are literally opening every door (and every window) for you.    You feel very comfortable and excited about joining either one.   Even the commute is the same.

As expected, two offers have arrived.  Both are very attractive.   How do you decide?    Simple – the company which exhibits and encourages ‘organizational courage’.   So how do you learn – as a brilliant software engineer – if the company does exhibit ‘organizational courage’ and why it’s even important?

Very few organizations exhibit what I call ‘organizational courage’.   It can only exist if the leadership team actively promotes and encourages ‘organizational courage’.

How do you find out if the company exhibits ‘organizational courage’ during the interview process? 

I hired an amazing software engineer some time ago.  “D” came to me 4 years later and resigned.   I understood.  “D”‘s new role would be more visible and a much better fit for “D”‘s career goals.   There was little I could to retain “D”.

Over lunch (the right way to do exit interviews), “D” smiled and told me how he evaluated my offer and the offer from another company.  I remembered that stressful week waiting for ‘D” to respond to my offer.    “Why did you accept my offer?”, I asked “D”.  ‘D” replied, “You were the only one who gave me an honest response to what happens if the product management team does not provide detailed specifications on time”.

“D” even recalled what I told him during the interview.  “Slow down the release process, do not code fictional functionality, and get detailed specifications – even if someone does not sleep for a couple of days.  Or – product managers and engineers enter one room and do not leave until everything is clear.   Again – no fictional functionality based on fictional requirements just to meet the release date”.

“D” said, “I knew that that’s the team culture I wanted to be a part of”.    Although “D” did not mention it by name, ‘organizational courage’ is an important element in evaluating several, seemingly perfect offers.

During the interview, ask probing questions to create your own understanding of whether the culture you may join exhibits ‘organizational courage’

– What happens if the release is late?  How do you perform lessons learned?  How do you apply lessons learned?

– What happens if the professional services team is very unhappy with the installation process, configuration capabilities, or error reporting?

– Is there a customer that is genuinely dissatisfied?   What are the root causes?  What are you doing about it?

– What is your track record making and executing difficult decisions – but for the right reasons?  Can you provide examples where the goal was not to reach a compromise but to deliver what the customer really needed to be successful?

Why it’s important to learn about ‘organizational courage’ during the interview process

Your career progression depends on it.

Why promoting ‘organizational courage’ makes perfect sense to any manager

“D” left my team but recommended his former co-worker, “J”, who turned out to be a terrific engineer.   Time from open requisition to hire to closed requisition:  6 days.    “J”‘s comments after spending the first week, “This is the best place I ever worked”.

Hiring a mobile apps software engineer: what to look for

September 25, 2012 Leave a comment

One of my former managers called me last night.   “Steve” worked for me several years ago.  Three months ago,  “Steve” was actively recruiting 2  mobile apps engineers to support both iPhone and Android platforms.   The search has been very difficult due to a shortage of qualified engineers.

“Steve” still had many resumes from great engineers who had limited experience developing mobile applications.   Could the right candidate be among these engineers?  I shared with “Steve” several suggestions to help identify the right talent.   There months later, “Steve” happily extended  offers to 2 engineers.   Both turned out to be fantastic members of the team.

What should a hiring manager look for in a software engineer who will develop mobile applications?   Believe it or not, the number one item is not whether the engineer knows Objective C or Java.

#1:  Does the software engineer understand the five dimensions of mobile design context: location, locomotion, immediacy, intimacy, and device?  (source:  Forrester Research)

Location:  mobile users can use their devices wherever they are

Locomotion:  mobile users can use their device while on the go:  in the car, running, walking.

Immediacy:  mobile users can user their device at a moment’s notice

Intimacy:  mobile users can use their device for different purposes.   Device use can vary from a digital appendage to an occasionally used device for a specific personal or work task.

Device: mobile devices vary greatly in form factor and capabilities

#2: Does the candidate show a deep appreciation for solving problems that may arise while the software is operating in a mobile environment?

– What if the network is not available or signal is lost every 2-3 minutes?
– Are there any functional scenarios sensitive to latency issues?
– Security?  Authentication?
– Diagnostic capabilities?

#3:  Can the candidate select (and defend) a solution approach while considering three implementation paths?  What implementation path might be a better option for a given set of functional requirements?

– Native
– Hybrid:  where HTML5 is rendered inside the native application

#4:  Can the candidate describe, design, and implement a testing framework for the mobile application?

#5:  Can the candidate give examples of mobile applications which can serve as an example of user interface “done right”?   Why?

Then – and only then – it’s helpful to learn about specific technical skills and experience:  Objective C, Cocoa Touch, HTML5, SQLite (for Android) …

The next fantastic mobile engineering hire is only a few questions away.

Do Google style interview questions illuminate the talent in front of you?

July 31, 2012 3 comments

In December 2011, The Wall Street Journal published an article How to Ace a Google Interview. But do Google style interview questions help determine if the candidate represents the best fit for Google?

The best fit … any hiring manager looks for the best fit.   But can Google – and anyone else asking the same style questions – determine the best fit without creating a practical framework for the hiring decision incorporating both tangible  factors (experience, skills, problem solving depth) as well as  intangible factors (personality, composure, ethos)?

The best fit is not a mystery. Determining the best fit by the hiring equivalent of alchemy creates an enormous disservice to both the candidate and the company.  At stake:  the success of a company, its products, and customers.

Hiring decision is a highly educated, fact based hypothesis that the person receiving an offer will create significant value in the organization while working with others.

I will highlight at the end why the best fit is not a mystery and should never be a mystery.

Why don’t we create a virtual interview and ask the same question being discussed in the Wall Street Journal article?

“You are shrunk to the height of a nickel and thrown into a blender.  Your mass is reduced so that your density is the same as usual.  The blades start moving in 60 seconds.  What do you do?”

I suggest reading  How to Ace a Google Interview to appreciate the answers to the above question.   Throwing loose coins from the pocket with hopes to jam the blades isn’t likely to impress the interviewer.

Before providing my own answer, it’s helpful to understand the motivation behind the question.   If a software engineer is faced with a seemingly impossible situation, what will he / she do?    The truth:  direct answers to an impossible situation do not provide any valuable information about the candidate to the interviewer.  The person will only become a victim of his or her own failure while trying to answer the question.  And the interviewer will not recognize depth of one’s talent.

I also ask questions that may seem impossible to answer during my own interviews.   But I try to work with the candidate by providing clues and alternatives to learn more about the candidate’s problem solving approach.

So why would one ask these questions?   I have a completely different motivation for asking impossible question.   I want to see candidate demonstrate the following  ‘genes’:

–       Accept failure / it happens

–       Learn from the failure / convert lessons learned into actionable plan

–       Quickly change the conversation and refocus on either preparing for this situation or avoiding it all together? Remember one of the best books written on the subject, “Only The Paranoid Survive” by Andy Grove, former CEO of Intel Corporation?

–       Tell me in detail how they would prepare for this situation and be better equipped to handle it

–       The best candidates will even prepare an action plan for dealing with any aftermath of the problem being addressed

It’s time to put myself in the spotlight and answer the same question.

“I am very glad you asked me this question.   This particular problem already happened to a colleague of mine and I learned from the unfortunate incident.   Should this problem happen to me, I have 3 methods to deal with this problem:

–       I always have a portable laser device with me.   It will cut through the blender glass within 10 seconds allowing me to exit before the blades begin spinning.

–       If the laser device fails, I will use a high frequency sound generator.    The glass will shutter within 8 seconds.   I prefer to use the first option and prevent the broken pieces of glass flying in all directions.

–       If the first 2 methods fail, my portable electro magnetic pulse (EMP) generator will fry the motor inside the blender but will also affect the microwave nearby

–       All three devices have already received appropriate regulatory approvals

As you can see, the blender will be inoperable after my successful exit.   So I took the liberty to order 2 replacement blender glass containers after each incident.  The blender can be immediately returned to service for the benefit of our customers.  Do you have any additional questions for me?”

Google hires very smart people.   But in the business of software, even smart people can still fail by failing to create commercial value from an idea.

Here is a partial list of of products Google launched and discontinued:

–       Aardvark

–       Google Answers

–       Google Buzz;  launched in February 2010;  discontinued by the end of 2011;  less than 2 years in operation.

–       Google Desktop

–       Google Directory

–       Google Fast Flip

–       Google Health

–       Google Gears

–       Google Squared

–       … and others …

Many Google employees (including product managers who ultimately set the product direction and determine commercial roadmap) worked very hard on products listed above.    Imagine the aggregate investment of time and money invested in these products.   It’s not trivial.    This investment can also be seen as a lost opportunity because these bright product managers and engineers could have worked on something with a much greater commercial potential.

Would the outcome be different if Google focused on a different set of questions during the interview process?

“We are thinking of developing Google Buzz.   What do you think about it’s potential?  What about the competitive landscape and risks?   How would you maximize the chances of Google Buzz succeeding?

That’s why the best fit is not a mystery.   The questions during the interview process must be relevant, including the motivation behind seemingly impossible questions.

Final point: never leave the candidate alone with their own sense of failure – no matter how small or big  – during the interview.   Because you still have to coach and mentor a newly hired superstar who happened to answer the seemingly impossible question to your satisfaction.   Career long coaching and mentoring is a better predictor of success than an answer to an impossible situation during an interview.

How to practically guarantee an offer to become the new CTO

March 29, 2012 1 comment

Highly admired, rapidly growing technology company has been searching for a new CTO who would play a critical role in the company’s next growth cycle.

You – the reader – were selected as one of the top 10 candidates and later as one of the two final candidates.   However, the company decided to hire the other candidate.  Why?  The truth is – you will never know.   But with hopes to help anyone being considered for a senior technology leadership position, I wanted to provide more visibility about the reasons why a seemingly terrific candidate ultimately did not receive an offer.

The top 3 reasons why the offer has not been extended to you:

1.  You did not ask the right questions, in the right sequence.

2.  You did not explain correctly what you would doing next Monday in your new role as a CTO

3.  You did not exhibit enough evidence of being able to quickly win the respect of both technology organization and other executive peers.

You did not ask the right questions, in the right sequence.

The job of any CTO in a software company is not to manage technology but to ensure that technology strategy supports the economic goals of a business, or 100% alignment between different phases of growth and how technology must evolve to support each phase of growth, while thoughtfully recognizing that some key initiatives must be sponsored and financed well in advance.

You must learn as much as possible about the company’s business during the interview process – in the right sequence.

First – learn about the company from the CEO (not an exhaustive list):  roots, key evolution milestones leading to the present, broad market conditions, major competitors (VP of Sales will provide more details), capital structure, investor profiles, investor goals, and resulting financial targets as well as time constraints.   It may or may not be possible to grow revenues 200% in 3 years.   These matters will have a significant impact on you as a CTO.

Second – ask to speak with the CFO.   That’s right – the CFO.   He / she will share with you how the company’s strategic plans are translated into operational plans and budgets which include all other organizations.   Is there a history of underinvestment in the technology organization and product engineering?   What’s the budget history of the technology organization during the last 3-4 years?    Are you walking into an organization where you may not have the right budget to ensure the success of the product development goals?  Or – the organization is mature enough to have a meaningful discussion and agree with you (hopefully the very leader being sought), even at the price of reducing investment in other areas?

Third – speak to VP of HR.   Learn about the state of technology organization / ask for the organizational chart.  Compensation – is it competitive?  Are there any open requisitions?   Imagine a growing organization where a principal level engineer role has been open for 6 months.   Why couldn’t the right person be hired?    Start making notes.   Can you have a meaningful conversation with VP of HR if the compensation structure in the technology organization you are about to inherit and lead is inadequate and about to trigger significant attrition?

Fourth – speak with VP of Sales.    What are we selling?   How?   Are the customers happy?  If not – what are the reasons?   Is there a detailed win-loss analysis process?   Can you get a copy of the latest report?

Fifth – speak with VP of Marketing and Product Management.   Is the requirements management process rigorous?   Are the requirements collected from all the channels:   customers, competitive intelligence sources, professional services?   How are the requirements managed:  documents or requirements management system?  When was the last time the product roadmap was changed?   What were the reasons?   How did the organization respond to some critical features being delayed instead of accelerated?   Ask for the product roadmap presentation.

Sixth – speak with VP of Professional Services to validate the state of the customer.   Is the customer community satisfied?   What is the typical deployment process:  duration, complexity?   How can the product be improved to reduce the complexity of the customer deployment process?

By this point, you have demonstrated 2 items the executive team is looking for:

– Ability to learn about the business from key executive peers (something you will have to do anyway but the key is to demonstrate this competency during the interview process)
–  Ability to extract key insights which will allow you to begin thinking about aligning the goals of the technology organization with the goals of the company

You did not explain correctly what you would doing next Monday in your new role as a CTO

If someone interviewing you asks, “what would you do during the first 90 days”, chances are your value as a candidate has already eroded.   Do not wait until this question is asked.

Find the right moment to mention that you are already thinking about the plan.   But before proposing the plan, you need to learn a lot about the business, your own organization, as well as every other organization that are critical to your success.

What every CEO is looking for in a new CTO when the CTO discusses the 90-day plan:

– 0 – 30 days:  make no changes in the technology organization.   Engage every employee.  Listen & take notes.   Resist every temptation to make significant changes.   Focus on creating a culture of transparency and accountability.   Team superstars will respect you from day one.  Underperforms will realize that the time for a new job search has arrived.

– 31 – 60 days:   become a silent participant in all other meetings.   Attend sales pipeline reviews.   Attend customer account planning calls.   Learn the pain points in every other organization that may be addressed later by adjusting the product roadmap or simply correcting product functionality.   Win the respect of your executive peers by sharing their daily challenges.

– 61 – 90 days:   Invest time in creating a very clinical perspective on what you learned.   Present it to the executive team.   They may not even realize certain issues or opportunities exist.   Then begin working on a plan to meet current operational goals while introducing methodical changes to position the company for growth.   Present it to your own organization.   Do not hold back any information.   Your commitment to transparency and clear goals will be the reason why everyone will accept you as the new leader.

You did not exhibit enough evidence of being able to quickly win the respect of both technology organization and other executive peers

The best part about item 3:   if you have done well with items 1 and 2, this one becomes a non event.  You have already demonstrated your ability to win the respect of everyone you will be closely working with.

If you act as a CTO while being interviewed for a CTO role, the offer to become the new CTO will be practically guaranteed.


5 mistakes growing companies make when hiring a CTO (the results could be fatal)

The examples of hiring the right person for the job – outside of the software business – are everywhere.

– Passengers on a Boeing 737-800 know that the pilot in command has been properly trained to fly this aircraft
– Passengers on an Airbus A320 know the same
– The country or state where you reside asked you to pass a driver license exam in order to drive

Yet growing technology companies make mistakes – often fatal mistakes – when hiring a CTO, in this case someone who will play a leading, critical role in formulating a technology strategy (with a plan to deliver of course) in growing the business.

Mistake 1:  Failure to ask the right questions and assess how you – as a company – arrived at the present moment in time

“There is a reason why today is meaningless and meaningful at the same time.  Meaningless – because today is simply an outcome of everything we have done yesterday.   Meaningful – because everything we do today will influence tomorrow.”

– Are you a company that has evolved via acquisitions or organic growth?   How would you rate yourself against the industry and closest competitors?
– Who is your competition?  How well do you know your competitors and their technology leadership team?    Will your new CTO be as capable as their CTOs?
– What is your growth strategy?  Is there an organizational strategy to support the growth strategy?
– What is the true state of the product?  Zero technical debt or lots of technical debt?
– Is there tension between members of the executive team?   There is always some healthy tension.  But – is there a fundamental misalignment between the strategic agenda and the ability to execute?  Would the new CTO simply add to the tension and – despite their best efforts – fail early?

Mistake 2:  Failure to create a clinical competency matrix which clearly defines who we want as the new CTO

Yes – the competency matrix has to be clinical (or “binary clear”).

Imagine the following scenario.   The new CTO joins the company and quickly notices that the sales team is actually very average.   What’s the point of building a fantastic product if the sales team cannot sell it?   Removing the constraints of organizational boundaries, what is the right thing to do?   Will the new CTO have the organizational courage and maturity to engage and help the sales team sell?  And if this approach does not work, approach the CEO and explain the problem?

That’s why Mistake 1 above is the one that almost always leads to a fatal outcome.   Growing companies that do not know themselves – or fail to learn about themselves – have very little chance of successfully hiring the right CTO.   Unless the company knows itself, it cannot create the very matrix which will define the right CTO against which the candidates will be compared during the search efforts.

Mistake 3:   Failure to hire the right candidate vs seeking “safe” candidate

“Safe” candidates are very attractive:  do not have to relocate anyone, may be coming from the competitor (but are they capable of quantum innovation or simply able to avoid mistakes that the competitive circles already know).

The right candidate are much more difficult to identify unless the competency matrix is “binary clear”.   Once identified however, open all doors to get this person onboard.

Mistake 4:   Failure to accommodate the friction which is always associated with progress

The right candidate will cause friction.  It’s inevitable.  Progress is impossible with friction.

Does the executive team understand the strategic direction and how the newly hired CTO will help achieve the desired business outcome?  Change will be inevitable and with progress friction will arrive.   Is everyone truly ready for change and some healthy incremental friction?

Mistake 5:   Failure to support the newly hired CTO

Newly hired CTOs fail for many reasons.   One of the major reasons is failure to understand and engage their team.  I always suggest that any new CTO should spend the first 30-45 days in the trenches to understand everyone’s challenges and needs.  Only then the new CTO will have enough organizational capital to  describe the mission and inspire everyone to follow.   The second major reason why a new CTO fails is lack of support from the executive team that invested an incredible amount of time (and sometimes money) to find the right person and not the “safest” candidate for the job.  As an agent of change and progress, the new CTO will be a messenger of disappointing news in the beginning.   One of their early goals is to understand what works and does not work before suggesting a specific course of action.   Do not shoot the messenger.   If the new CTO fails, you will fail with him or her.

Why do we succeed as individuals yet fail as a team (how to move beyond collaboration … )

December 4, 2011 Leave a comment

This is the time of year when many software companies are getting ready for the new fiscal year.   If you are CEO or COO (or a someone in a senior role in a software company), these questions are already on your mind:

– Will we meet revenue and margin targets?

– Where will the revenue come from:  markets, customers, products?

– Will the Marketing team counter competitor’s messages?

– Will the Product Management team continue to define the product roadmap in “The Three Horizons of Growth”:  now, tomorrow, some time after tomorrow?

– Will the Engineering team deliver the products according to the product roadmap?

– Will the Professional Services team be able to service customers across the globe?

– How do we hire the right people?  Where are they?

Several years ago about the same time in December, I was asked by “Linda”, CEO of a growing software company, to attend an annual operational review.   She simply introduced me as someone who came to listen.   Every executive presented an overview of their organization:  in short – more highlights than lowlights.   Every executive gave themselves a grade between B- and +.

“Linda” patiently listened.  She then picked up 3 software industry trade publications and began to mention …

“On page 20, this customer is expressing a severe disappointment with the installation of our latest release”

“On page 11 of a research article, there are very alarming words that we quickly falling behind the competition in these core areas”

“On page 44 of another magazine, there is a survey which indicates we are dead last when it comes to customer support satisfaction”

“Linda” looked around the room, paused for a moment and then asked, “Why is it you – my executive team – are so successful as individuals yet fail as a team”?

The silence in the room was a sobering experience.

“Linda” and I met the very next day.   She asked me to reflect on what I learned during the operational review.   My perspectives were very similar to what “Linda’ also observed:

– The fabric of collaboration between executives has no teeth.   Every is free to collaborate but no one has a stake – real stake – in the success of their peer.   Peer relationships do not have shared incentives to ensure success.

– Some executives have to change roles to appreciate peer’s pain.  Some will will succeed as soon as the new system of shared incentives is in place.   Others will not succeed because the the new system of shared incentives will quickly expose their shortcomings.

“Linda” agreed that changes were necessary.   The transformation journey was not easy – in some cases very disruptive – but “Linda’ remained committed to the outcome.    This company is now doing very well and in fact purchased one of their competitors.

So what did “Linda” and I change?

– VP of Sales could not make the transition from selling transactions to selling solutions.    He was more interested in the next deal then the total value of the account, which of course depends on the customer satisfaction.   If no one is satisfied, how does one create a reference account?   Without references, the average duration of a sales cycle gets longer and the problem is now a cash flow problem.   After a new VP of Sales was hired, the compensation of the entire sales team was changed.   Part of their commission was now linked to the customer satisfaction during / after deployment cycle.   This is where shared incentives really matter.   Professional Services team is responsible for customer deployment process.  Sales team has to work with Professional Services team to ensure success (and get the rest of their commission).

– VP of Engineering was seemingly in a continuous state of failure:  release were late, constant quality problems.    The reality turned out to be very different.   VP of Professional Services was not interested in sharing customer problems with VP of Product Management.   Installation problems never received attention in the product roadmap and did not result in a new requirement linked to a timely release.   Neither VP of Product Management nor VP of Professional Services spoke on a weekly basis.

– VP of Engineering became CTO (with Product Management and Engineering reporting to one person – complete accountability for the product).   He knew every painful area in the product portfolio and had a better relationship with customers (unfortunately due to so many defects being reported by the customers which were not addressed in the product rodmap).   VP of Product Management became VP of Global Accounts.    His new charter became very simple:  take care of these key customers – make every one of these a reference account, or your bonus and possibly job are at risk.   Shared incentive:  the product has to work in order for VP Global Accounts to be successful.   The new CTO and VP of Global Accounts began to work very closely together.

– VP of Professional Services had to leave, unfortunately.   “H” could not operate in a new system of shared incentives where part of his compensation depended on the quality of customer deployment and support experience.   To succeed, he had to care about customer reported problems and take an active interest in prioritizing these problems in the product management discussions.

“Linda” and I still continue to talk.  The hardest part is making the decision to move beyond simple collaboration to a system of shared incentives where collaboration truly works because the system of rewards and punishments also works.