What if being stellar is not enough?  For software companies building enterprise, mission-critical products capable of operating in a global, 24/7 environment, learning if a candidate can build resilient software is often another critical discovery goal during the recruiting process.

The definition of resilient software can be indirectly highlighted by an example everyone – and I mean everyone – would rather avoid.

Imagine being a pilot guiding a single aisle, 300-passenger aircraft on final approach.   300 passengers cannot wait to get home.   At an altitude of 4,000 feet, both MFDs – or multi function displays – suddenly show a message:  Unhandled Exception.

What’s the problem?  The software controlling both MFDs is not resilient enough during the most critical operation.

When hiring senior and principal software engineers, I always try to learn to what extent the candidate respects the goal of resiliency and believes in building resilient software.   In my experience, there is no such thing as “just enough resiliency”.

So how can we find out if the candidate can develop resilient software?

I suggest to structure a simple problem which can be asked during the interview.    It needs to be simple in order to get the most of the first interview.

One of my favorite interview question is about 2 threads:

- Thread 1 writes a file
- Thread 2 reads the same file and creates a copy

Simple.

“How can you accelerate this process?”   Most candidate will identify the need for Thread 1 to write data in blocks while notifying Thread 2 to process block N-1 while writing the next block.

“How can you still accelerate this process?”   Fewer candidates will identify the need to create an in-memory structure – created by Thread 1 – which Thread 2 can use instead of reading the file.

“How can you squeeze more performance?”   Very few candidate can identify more performance improvement options at this point.   Yet there are more options.

Now we can start asking very probing questions intended to learn if the candidate can build resilient software.

“How can you avoid excessive memory consumption in the above scenario?”   How could you monitor the memory consumption?   What if the memory was very limited?    How would you adjust your engineering approach?

“Let’s pull the power plug.  The server is down.   How can the above scenario continue running after the server restarts?”

“Imagine this scenario running on a remote server, 4,000 miles away.   Can you build a quick monitoring / alert management component?  What does it look like?”

Simple problem.  Yet very useful to determine if the candidate can build software which goes through great pains to avoid Unhandled Exceptions at the most inconvenient moment.

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

You just learned that one of your best software engineering managers is leaving the company.    Rapidly growing, still private “always in the news” company made an offer that no one could refuse:  great salary, stock options, complete freedom to build and operate a team with critical and exciting challenges.

You start interviewing candidates.  It’s very likely that at least 100 good candidates will go through a recruiting process (if including candidates seriously considered by a recruiter) before 10 excellent candidates with a strong potential may emerge.

I realized that this blog entry is almost a necessity after interviewing three candidates recently.

Thinking like a candidate for a moment …

You will fail the interview very quickly unless you can demonstrate your commitment to software engineering management fundamentals.   Let’s work together and try to become the best candidate for the job of an Engineering Manager.    What are these fundamentals?

1.  Ability to take ONE objective (for example:  a new product) and methodically decompose it into MANY components, features, functions.   Can you decompose a computer into a logical component model?   See below for a a real life example from a recent interview.

2.  Once Number 1 is known:  ability to translate into roles and skills required to execute?  For example:  a UI intensive product will require some number of UI engineers.   How many do you need?  10 or 1,000?  Can you justify your answer?   The accuracy of your answer will lead to either the right amount of money spent or lots of money being spent.   Product profitability may be at risk.

3.  Once Number 2 is known:  ability to hire, lead and manage A+ engineers.  Do you know the difference between a great engineer and a stellar engineer?

4.  Put 1 and 2 on the same page.   Can you show on the schedule how all components / features / functions will be engineered and properly tested?

5.  Then execute.   Can you manage the engineering process and adjust, adjust, adjust – without compromising the objective?

“Can you decompose a computer into a logical component model” is one of my favorite interview questions.   If a candidate cannot envision the final deliverable and how the building blocks have to be engineered, he / she will not succeed.

One of the candidates interviewed by me recently provided many valuable insights that I’d like to share with prospective candidates and hiring managers alike.

“Frank” began to quickly identify components of a computer:   keyboard, monitor, CPU …

The first two components – keyboard and monitor – are very good answers.   Is CPU a good first answer?   I asked him to tell me if CPU is a valid component at this point.   He could not answer my question.   I asked him how the keyboard talks to the CPU.   Where is the linkage?    After some time, Frank correctly identified motherboard as the next logical component, which does have a CPU and a keyboard controller attachment.  Now the linkage can be made.

But why is motherboard an important component at this level?  He could not answer this question.

Because the motherboard …

- Is of a certain size and will drive the requirements of another component:  desktop case or laptop form factor
- Depending on the case, it may need certain cooling requirements (one or two fans)

The answers are not important.  What is important for an engineering manager is to demonstrate what I call ‘component awareness’ which drives many other requirements:  interfaces between components, requirements of other components, integrating testing needs.

Unless someone can see the bridge, one cannot hire structural engineers to build the bridge.  Which bring me to the next fundamental competency a candidate must demonstrate:  ability to hire, lead, and manage a team of A+ contributors.

Other than skills and experience, stellar engineers (true A+ contributors) have consistently demonstrated the natural ability to coach and mentor other engineers.   If you can hire engineers who can organically replicate excellence in the team, you will be a better engineering manager because you will deliver a much better product than your competition.

Please do not fail the next interview for an Engineering Manager.   Focus on the fundamentals.   Become the best candidate.

Can the software industry teach Washington and perhaps Brussels (EU) something of value?

I rarely write about political topics (although I am very much engaged).   This is the first time I decided to write a blog entry which will hopefully resonate with everyone.

Let’s imagine a conversation where your child will ask you several questions.   Children have a rare, non-biased ability to see through the ‘mist’ and ask very direct questions.

1.   Daddy, I would like to become a software engineer in 10 years?   Will I have a job in the United States? 

Yes.   But only if you make a fundamental commitment to become the best problem solver first.   Then – you must become a master of technology who creates software that works correctly, the first time.   Nothing less will do.

Chances are you will be quickly hired by a small, dynamic company and later acquired by Facebook or Google because both companies cannot hire great engineers fast enough and choose to acquire smaller companies because of the talent these companies were able to find and develop.

Do not plan to enter the software industry because of high compensation alone.   The software industry is going through a fundamental shift:  software everywhere means more complex, 100% reliable software everywhere.    Mediocre engineering skills are no longer needed.

2.  Mommy, what if I don’t have enough money for college? 

In the US, official unemployment is approximately 9%.   Unofficial unemployment is much higher.    Yet, software companies cannot find enough qualified candidates.   Why?

“The mind is a terrible thing to waste”.    During the last 20 years, the United States educational system simply failed to produce enough engineering talent.

It gets worse.    Foreign-born engineers and entrepreneurs are moving back to their home countries and creating businesses there instead of the US.    Fewer business means slower employment growth and less revenue for the cities, states, and the Federal government.

Can it get worse?  Yes – public education spending is under severe pressure while private colleges are becoming more expensive, exceeding the rate of inflation by a wide margin.

Can it get any worse?   Yes – many parents took equity loans from their houses to finance the education of their children.    The housing crisis,  the recession of 2008, growing unemployment, and depreciating housing values left many parents no choice but to file for bankruptcy.

Message to Washington:   while running for office, almost every candidates talks about “better education for our children”.    Scorecard after being elected?   Poor at best.

3.   Daddy, what if I get sick after graduation and do not have a job yet?   What will happen to me? 

Very good question.    How does one put a price on a healthy work force?    Why does Switzerland see the healthcare problem differently than the US?

I know many small software companies that failed because they were simply not large enough to obtain the best prices for health care coverage for their employees.   What if they could obtain reasonable coverage for their small, but very bright work force?   How many future “Apples” are not longer in business?

Message to Washington:   please stop using labels, such as Obama Care without offering real and practical alternatives.    Please solve this problem.   Or – do not run for reelection to allow other, more capable citizens to work together and solve this problem.

4.   Mommy, what is better?   More government or less government?  

The real purpose of government has been forgotten in this debate.    The amount of air time dedicated to “what Obama should do to create jobs” has exceeded every record (if records were to be kept).

Unless Obama puts everyone on White House payroll, the debate will continue without any tangible outcome.

The real purpose of the government (any government):   create a regulatory and legal structure to deliberately influence the economic development in a certain direction.  Measure and adjust as needed.

Then – within this structure, the market and economic forces will flourish.

Does everyone remember the promise of “green jobs” during the last Presidential election?

Just recently, Solyndra – a  US based solar panel manufacturer in Fremont, CA – filed for Chapter 11 bankruptcy and laid off all 1,100 employees.  Solyndra was also a recipient of a $535M loan guarantee from US government with a very visible visit by President Obama in 2010.

During a visit to the Solyndra facility in 2010, Obama said the factory is “a testament to American ingenuity and dynamism and the fact that we continue to have the best universities in the world, the best technology in the world, and most importantly the best workers in the world.”

Ignoring for a moment the fact that Chinese competitors enjoyed bigger subsidies from Chinese government, that Tulsa billionaire George Kaiser, a key Obama backer who raised between $50,000 and $100,000 for the president’s election campaign, is one of Solyndra’s primary investors …

… what are the lessons learned?

Message to Washington:  the market consists of sellers and buyers, not just sellers of solar panels.   Do not stop at giving Solyndra money.   Create tax incentives for cities and home builders to use solar panels.   Create a market where sellers will begin to buy products from an emerging industry segment.

Be honest with competitors who get the benefit of deep subsidies.   That’s what trade tariffs  are for.     Moreover, treat taxpayer’s money like your own.   Manage the investment.

5.   Daddy, why is Apple so successful?  

Companies where innovation is the key enabler of success enjoy much higher gross margins than any other business.

Software is a high margin business.   Higher margins mean being able to hire valuable people who get paid more.   And these employees will have a larger impact on economy by being able to spend more.

It’s back to basics.    The economic impact of one $100K per year job is much greater than the economic impact of four $25K per year jobs.

Message to Washington:    please stop perpetuating the futility of empty economic promises  which have very little to do with a very difficult road ahead to put this amazing country back on the right track.

-       Focus on creating a legislative and regulatory environment where new high margin businesses can grow and prosper

-       Be honest with yourself.   Are you really doing everything possible “for the people and by the people”?

-       Do you remember the oath you have recited when taking office?

“I do solemnly swear (or affirm) that I will support and defend the Constitution of the United States against all enemies, foreign and domestic; that I will bear true faith and allegiance to the same; that I take this obligation freely, without any mental reservation or purpose of evasion; and that I will well and faithfully discharge the duties of the office on which I am about to enter. So help me God.”

-       Do you have the strength to tell your constituents that someone else should be doing your job instead?

Message to voters:   on this Labor Day, get ready to vote in November.    Or – do not complain.

The schedule of a major software development project has to be updated.   The team cannot meet original milestones and the project is delayed.

Ignoring the reality for a second, what if we had the luxury of going back in time and doing some things differently in order to create an accurate schedule the first time?   Is it even possible?   The answer is yes.

Before sharing my perspective on the problem of inaccurate software development schedules, it’s important to identify factors that cannot be controlled (not an exhaustive list):

- Highly competitive (do or die) market expectations and very aggressive delivery schedules;   this however does not mean taking significant shortcuts in functional depth or product quality.   The risk of delivering an underwhelming software product to a market closely watched by industry observers and analysts cannot even be measured.   My guidance:   simply don’t deliver an underwhelming software product or release.

- Deep and unknown technical debt can surprise even the most capable software engineering teams.    Large scale refactoring efforts carry a lot of risk despite best efforts to manage these risks and schedules.    Technical debt gets even worse when it has been inherited.   Someone else wrote 1M lines of code and your team has to first understand what it does.

What factors influence the accuracy of software development schedules?   Is there a single factor which helps ensure accurate schedules more than any other factor?

People.

Because if the right people properly assess the problem, the result will be a better estimate.  There is no substitute for the right people who can understand the problem (at the right level of detail with all the right inputs and considerations) and determine options to solve it.

Only then the right process applies.    Many software engineering projects fail because a manager tries to apply a perfect process to a team that has difficulties solving the problem in the first place.   To illustrate:  it’s equivalent to asking an excellent driver to fly an Airbus A-320.   The driver will fail because he / she does not know how to fly this aircraft although the _process_  of driving a vehicle and flying an airplane is very similar.   The real problem is however not the driver who is being asked to be a pilot.   It’s the manager who creates this problem in the first place by asking someone who cannot be successful to step into the position of guaranteed failure.

Software engineering projects that suffer many delays show the same symptoms:

- Managers who exhibit “every leaking faucet is a plumbing problem” approach.   Different problems require a combination of techniques to assess and address in a sustainable manner.

- Software engineers who never refactored code and cannot apply a classic “cover and modify” technique.   Yet there are software engineering managers who will continue to ask their employees to do what they have never been exposed to.

- Quality assurance engineers who do not understand the full extent of automated software testing and tools (not every tool can be used for every automation challenge)

- Lack of continuous internal retrospection:   what do last 20 regression problems really mean?   Why did the team generate these regression problems?   What can we do better?   How frequently should these lessons learned exercises be conducted?   Once at the end of the release is not a good approach.

Simple steps towards an accurate software development schedule:

- If you are a manager, be very honest with yourself first.   Have you done this before?   If not – be the first to ask for help.   Assess your team.   Given the complexity ahead, do you have the right team?  If not – make changes.

- If you are an engineer, be very honest with yourself.   Am I up to the challenge?   Can I “fly this plane”?  Do I have the tools and experience?   If not – ask for help or be ready to ask for help.  Set your own measures of success.    For example, what if you were asked to help bring Apollo 13 back to Earth?  What would you do?   How could you contribute and help?

- Assess the problem correctly.   Let’s assume an engineer will work on 2 projects:   write a payroll program and write a virtual memory management component for a new operating system.   Which project will have more error management code?   Shouldn’t error management code and the effort to implement it be in the schedule?

Accurate software development schedules begin with people:  people who manage well and people who design and engineer the answer to the problem.    Both have to be first successful in one critical element:   assess the problem correctly.

Don’t forget to attract, retain, and reward great people in your software engineering organization.

Word documents capturing functional requirements …

Word documents – as attachments – capturing non-functional requirements …

I believe that the reason why this dialog remains very active is simple. Every framework, approach, methodology is – “a virtual construct upon reality” (not my words) that we – as humans – need as a structure to solve a particular problem.

Since every problem is unique, in almost every instance we need to find the right balance between techniques available to us.

The key in any problem definition:

- Identify interaction owners (call them actors, call them users – it does not matter)
- Identify all relevant interaction between these owners

There is absolutely nothing wrong to treat every interaction owner in any technical problem as a user and then write either Agile-centric description of the goal or Rup-centric description of the goal.

The real challenge is not writing the user story or use case in a pure format. The real challenge is to describe the problem in such a manner that it facilitates and expedites the implementation details in order to solve the problem correctly – the first time.

For example: let’s assume we are designing software which informs the pilot in the cockpit of the aircraft’s speed.

“As a speed indicator gauge, I need to be informed of correct airspeed by air speed sensor in the nose of the aircraft”.  This example clearly defines 2 interaction owners.

“As a speed indicator gauge, I need to receive information every 20 ms in a certain format”. This example defines the order of precedence and rules. The gauge has already been designed and available;  it has certain interfaces which influence data collection downstream.   We just have to honor these design elements in any subsequent interaction description.

“As an airspeed indicator, I need to measure the air pressure and convert this metric to something that speed indicator gauge understands, sent every 20 ms”. Do not know yet what the message format is.  But – engineering intent is clear.   These interaction owners have to find a way to talk to each other.

“As an airspeed indicator, I also need to inform another diagnostic device in the aircraft every 1000 ms that I am healthy and working”.  This is an example of an instrumentation requirement written as a user story.

The goal is the same: the functionality being developed must serve the consumer perfectly – as intended. The rest is simply how we get to the point of success.

Imagine if someone forgot to write the user story which captures the need to check periodically that the airspeed sensor is still working …

The results would be catastrophic regardless of adherence to any preferred process or methodology or framework.

Frame the problem correctly.  Then use all available techniques to solve it correctly.

It’s Friday PM.   You are VP of Engineering, reading a letter of resignation of a terrific engineering manager.   “G” is leaving to join a company for reasons seemingly impossible to overcome:  shorter commute, more stock options, as well as better compensation.    Thinking about the implications of this departure can spoil anyone’s weekend.

So what are the next steps?  Call every recruiter?  Not yet.

Immediately, evaluate yourself as a manager.   Regardless of the reason why someone is leaving, every departure is a reminder of the universal truth in technology organizations where great people are the key to success:  people do not leave companies, they leave managers.

Even if you are the best manager in the world, this departure will create an opportunity for you to become an even better manager.   By making the decision to complete your own self evaluation as a manager, you will be be able to retain other critical individuals in the organization.

On Monday, every attempt to retain “G” has failed.  Nothing worked.  “G” wanted to have a shorter commute and left the team in 2 weeks.

How do you look for that next perfect hire who will be able to replace “G” and become a highly respected engineering manager?

The immediate tendency is to look for another “G”.   This approach – although viable – will not answer a different question:   how do you find someone who is better than “G”?

Better “G” does not exist.   Better “G” can be developed by investing time in the new hire, by being his / her mentor.   That’s why it’ so important to perform your own self-evaluation.   Will you be willing to mentor and coach the new hire to become a better “G”?   If not – you will fail as a leader, and the new hire will probably fail as a manager.

As recruiters forward resumes to you and the recruiting process begins to produce good candidates, these candidates will most likely be in these categories:

1. Perfect manager.  Perfect technology depth.   If you can find this person  …

2. Perfect technologist.   Very good team leader.   Ready / willing to be a manager.

3. Perfect manager.  No longer willing to be a perfect technologist.

In reality, candidates in categories 2 and 3 will appear more often in the recruiting pipeline.

The candidate that shows the most potential to become a better “G” is Category 2 candidate.   But only if you are willing to invest in the new hire and coach / mentor him / her.

Great engineering managers are not hired.  They are mentored by great leaders who took the time to do what every great leader does well:   replicate excellence.

But it all starts with one’s self evaluation as a manager.

As a facilitator, I also managed to end this debate in many organizations.

This debate should produce a clear roadmap for the team to solve a real business problem where technology plays an enabling role.   However, this very debate has been the reason why so many technology initiatives have failed.

If you are a CIO, CTO, or technology executive being placed in the position of facilitating this debate in your own organization, I hope this blog entry will help you end this debate – for a long time (or at least several budget cycles).

This may be a surprise.   The very reason why this debate exists is because – despite your every effort as a leader – you haven’t shared with your organization  what I call CTO Manifesto:

1.  “We are in the business of solving business problems, better and faster than competition”
2.  “We view technology as a competitive differentiator, and plan to be better at this than anyone else”
3.  “We care about the top and bottom line;  technology investments will have a direct & positive impact on both”
4.  “While solving business and technology problems, every technique or tool will be used or combined to achieve Goals 1, 2, and 3″

Goal 4 – unless clearly stated and explained – will lead to a counter productive debate between Agile and every other AMF (see above).

Every problem any technology organization faces on the daily basis requires a thoughtful assessment, without a predetermined bias for a specific answer which may involve application of a specific solution approach.

There is simply no substitute for a proper understanding of the problem first.

Unless the problem is properly defined – and all implications on complexity, architecture, delivery timeline, integration touch points, skills availability, organizational / training impact are at least discussed – the decision to use a certain approach as an overriding principle to solve the problem will almost always lead to a failure.    This will not be a technology failure.  This will be a failure of the technology organization to deliver  a solution which the business desperately needs to enter a new market and generate the next wave of revenue.

Many industries have ended this debate by doing what makes sense:  first – understand all  critical dimensions of the problem, then apply the right mix of tools and techniques to solve it.

Example 1:  Let’s try to build a helicopter using a pure Agile approach

- Without knowing the speed and payload requirements in advance, it’s very difficult to delay worrying about the engine and the main rotor
- Without  a proper understanding of physics (the torque generated by the main rotor), the tail rotor design will be forgotten
- The first flight without a tail rotor will be disastrous
- But:  once the need for a tail rotor is identified, several engineering team can work in parallel and quickly iterate through multiple designs
- Waterfall and Agile do exist and work well in this example

Example 2:   Let’s try to refactor a very complex software product using a pure Agile approach

- This is a perfect example, because without a proper understanding of specific goals (improve performance?  improve ease of installation?  improve error management between several components?) and how technology may have to change to achieve these goals, the effort will most certainly fail
- Improving performance is one of the most complicated software engineering goals.   It involves a deep understanding of where individual transaction are spending time in each architectural layer.
- Sometimes there is a need to write additional code just to understand where transactions are spending time
- Then, based on risks and benefits, several prototypes may be designed and engineered to learn which refactoring approach may lead to targeted objectives.  And it’s not always optimizing SQL to reduce the data access time.
- But:  once one of the prototypes becomes the blueprint for the solution, multiple iterations can be planned (some could be even be planned in parallel to save time).
- Again:   multiple techniques are required to solve this problem

There is no need for this debate.   The responsibility to end this debate starts with you.

I had a conversation with one of my former clients.  “D” is a Chief Product Officer in a software engineering company with teams in multiple countries.

“D” and I worked closely in the past.  “D” also happens to be one of the smartest people I know.   But “D” was in trouble.  His efforts to create a world class global software engineering organization have failed.   He asked me to help.

If you are a CTO, VP of Engineering, or any senior executive who wants to design a global software engineering for success, this blog entry is for you because these are the problems you are facing:

- Increasing sense of urgency to deliver complex products faster
- Increasing need to deliver products which are tailored to operate in a certain region / country (but have a common architecture)
- People in one timezone can only accomplish so much;  need 24/7 engineering cycles

First – order these books:

- “The Five Dysfunctions of a Team:  A Leadership Fable” by Patrick Lencione” from www.amazon.com
- “Dealing with People You Can’t Stand:  How to Bring Out The Best in People at Their Worst” by Dr. Rick Brinkman and Dr. Rick Kirschner, also from www.amazon.com

Then – eliminate these expressions from your vocabulary:

- Outsourcing
- Offshoring
- Captive organizations
- Low cost labor

We are now ready to design a world class software engineering organization. Together.

Follow these ground rules:

- Teamwork – Part 1:  Superb people exist everywhere.  You just have to find them.   This means that a technical architect in Country A and a technical architect in Country B must exhibit the same technical depth and competencies.   They are exactly the same, but speak a different language.   Teams with superb engineers (regardless of where they are) will work together because they will gravitate towards each other.   Smart people want to work with other smart people.

- Teamwork – Part 2:  World class software engineering organizations are world class because of superb managers.   Imagine how difficult it is at times to make 2 people sitting in offices next to each other work together.   Now imagine the challenge of 2 people from 2 cultures sitting 6,000 miles away from each other – working perfectly well together.   Teamwork does not happen by a directive from me or any other executive.  Teamwork is enabled by managers who believe in, “if you take care of the who, the what and the when will come”.   Find these managers.   Hire them.  Get rid of anyone who does not believe in Part 2.   Do not forget to practice Part 2 yourself.

- Teamwork – Part 3:  Teams in a world class software engineering organizations enable each other.   They do not run away from each other.   Hiring superb engineers is a must.  But not everyone is a technical architect (1% of all candidates).   Implement “if you take care of the who, the what and the when will come” at the ground floor level by creating a formal program, where senior employees are responsible for enabling new hires in other countries.   It works very well.  “J” is a principal level engineer in Chicago.   “J” has been asked to mentor and coach “V”, a new hire in Country B.   “J” is responsible for enabling “V”‘s success during the first 6 months.   “J”‘s individual performance is tied to “V”‘s success.  If “J” cannot replicate excellence by coaching others, get rid of “J”.   Send a message.

- Teamwork – Part 4:  Shared responsibility for success is a common denominator in a world class software engineering organization.   Again  – do not send another email about this topic.   Make it extreme, where everyone has to breathe this concept.  Carefully deconstruct a large software product into smaller components.   Assign component ownership to multiple teams.   Neither team can succeed unless they collaborate and agree how all components work together.

If you haven’t ordered the first book, “The Five Dysfunctions of a Team:  A Leadership Fable” by Patrick Lencione”, please order it now.

Patrick Lencione could not have said it any better:

“Not finance.  Not strategy.  Not technology.  It is teamwork that remains the ultimate competitive advantage, both because it so powerful and rare”.

It’s very well known that the majority of individuals who elect to leave a company leave because they did not work for the right manager.   The reverse is also true.  Many individuals with multiple job offers will most likely choose an offer where they will work for the right manager.

So … what makes a manager the right manager to work for?

One of my former colleagues, “M”, called me and asked for my advice.   “M” is considering an offer from one of the best technology companies in the world.  It’s a great offer which comes with an added benefit:  several software engineering teams want “M”.

My advice:  select a team with the right manager.   “M” asked me the very same question, “how do I choose the right manager”.

I was glad to share my advice.  The right manager will …

- Lead first, manage second

- Listen first;  answer second

- Make every loser feel like a winner (up to a certain point)

- Always depend on why something is important for the customer as the reason for specific action

- Take an active interest in your career;  will cheerfully answer how he / she develops their team members

- Remain confident when surrounded by people who are much smarter

And – will always show signs of believing and practicing one universal truth …

“If you take care of the who, the what and the when will come”

I wonder how many readers of this blog will respond with a confirmation whether they are working for the right manager.