Development Partner Due Diligence

Recently, over tea, I was asked about offshore partners.  During the course of the conversation, I shared my thoughts about selecting a partner.  While not an exhaustive list, nor in a particular order, here are some thoughts I believe represent significant consideration.

Demonstrated technical competence

In what technologies does the partner claim expertise?  Regardless of whether you have a technical stack in mind or are deferring to the partner, you want confidence the partner has skill and competence. 

The strongest evidence is successful completion of projects using the proposed technologies.  Your partner ought to provide examples of other projects, including how the technologies were used, the extent to which they were used, and the results.  You want to know the projects were roughly comparable in terms of complexity (scope and team size).  If not, then you want a clear picture of how the partner can scale their experience to meet the demands of your needs.

Second, ask for corporate credentials or relationships that indicate expertise with the given technologies.  For example, if the partner claims extensive .NET experience, ask them to elaborate on their relationship with Microsoft.  I'm not talking about getting a certification for buying a bunch of Microsoft stuff.  I'm talking about actually engaging the Microsoft developer tools and technology program teams. Have they participated in any Microsoft ISV programs?  Have they been in a TAP? While not perfect, this can give you a sense that they have invested additional effort in mastering one or more technologies.

As a concrete example, a partner I work with has the largest absolute (and as a percentage of staff) number of HL7 certified developers on staff of any company I know on the planet.  This is a strong signal of their deep organizational commitment to healthcare interoperability.

Reference customers

Your partner should have a set of customers willing to talk to you.  I like to ask for 5-6 customers.  Some in related fields and some not.  Then I pick some (or all) and call them.  Here are some of the questions I typically explore:

• How does the partner handle the contracting process?  What about changes? I want to know if the contractor views this as a transaction or a relationship.
• Are the people on the team the same as the people that were introduced during the sales process?  I want to know if I can trust the partner, or is this going to be bait-and-switch.
• How is the quality of the deliverables (not just the software)? How are quality problems addressed?  I want to know if the partner takes pride in what they produce.
• How is the interaction with the partner's leadership team?  How would you describe their character?  Organizations take on the characteristics of their leaders.
• If you have visited their location, describe the physical environment (including hardware and equipment they have) and work conditions.  Is it a sweat shop or do the employees appear well cared for?  This impacts turnover, and consequently, the overall productivity of the team.
• Have you awarded the partner additional business since you begin the relationship with them?  Yes or no, why?  You can finesse the other answers, but where you put your money says a lot.
• If possible, describe briefly your project.  Ask the reference if they would recommend the partner based on your description.  Arguably, it might be little to go on, but you would be surprised.  You may describe a highly technical research project and find that the partner is better suited at a well defined line of business application.

The team

Ask for resumes or biographies of the key team leaders that will be assigned to your project.  Don't accept "representative" overviews.  Get the details of the specific people that will be assigned.  And be sure to interview them to verify their credentials and background.  You should treat these key leaders no differently than if you were going to hire them onto your team directly - because that is what you are doing.

In addition to the team itself, ask about their training program.  Elements you should look for include:

• New hire orientation programs
• Domain specific training (e.g, Healthcare, Banking, etc.)
• Function specific ladders with associated expected skills (e.g., Junior Developer through to Developer Team Lead)
• If appropriate, language and communication skills training

The best partners I've seen (and therefore, do business with) are able to tell me, "When you hire a Senior Java developer, you are assured they have these skills, each at this level, and will receive the following training in the coming year."

Again, this is not an exhaustive list.  But it should get you thinking about more than just cost rates.  Leave some of your questions or other items as comments.  I'd love to hear what you think.

Hire for attitude

I was chatting with someone the other day (as opposed to chatting with myself - but that is another story...) about the state of talent in our industry. I relayed to him a quote I learned from Michelle Jackman (http://www.mjbizwiz.com/) many years ago: Hire for attitude and train for skills.

Given that I heard this from Michelle in 1988, it is among the most impressionable things I’ve learned in my career. Along the way, I’ve discovered a few things that help me assess a potential team member’s attitude. This is not an exhaustive list, and I welcome your thoughts.

Focus on principles, not tools
The best candidates (and subsequently, hires) have been the ones with whom I’ve had a conversation about software engineering fundamentals and principles. How do they view design? How do they view build management? Does the art and discipline of software development excite them? If none of this matters to them, I don’t care if they know languages and data structures.

You may be asking, “How do you know if they actually have skills, though? These sound like philosophical conversations.” You are correct - they are about philosophy. However, if you dig deeper, you’ll realize the candidate has developed their philosophy through their experience and learning. A candidate can’t talk to me intelligently about multi-branch, concurrent release management unless she has dealt with it in her career. I don’t necessarily care if she has used CVS, Subversion, Jazz, or ClearCase. What I care about is that she experienced the challenges with this and has developed principles about release management that are consistent with (or will add to) mine.

In addition to software engineering principles, a person must love to learn. I ask things like what websites and journals they subscribe to. I ask them what the last couple of books are that they’ve read. Candidates that come up blank are not asked back. If the candidate shows no interest in learning on their own, they aren’t going to be fit on my team.

Focus on customers, not process
I want to know if the candidate wants to be left alone to code or understands that we build software for people. If the candidate shows little to no interest in the customer, they don’t get on my team, regardless of talent.

I had a key senior architect who I wanted to accompany me on a customer visit. This was a key customer, with a team of highly technical staff. My guidance to my architect consisted of something like, “We are visiting customer ABC, to discuss our foo-bar capability. They are going to have several of their technical folks at the meeting. I want you to discuss our architecture with them. Take care; I’m on the road for the next couple of weeks. See you at the customer.”

He prepared customer friendly architecture drawings. He kept me posted on progress and asked my thoughts about the overall level of discussion and breadth of topics. In other words, he demonstrated the attitude that customers are important, and that we need to be prepared when meeting with them. That attitude, by the way, was infused into his designs.

His response was exactly what I expected based on our conversations during the hiring process. My faith in him was not drawn from his technical ability (although it was very high). It was drawn from knowing his attitude about software engineering and customers.

Concluding example

I once was approached by a person who wanted to join my team. He was a developer earlier in his career and then a manager for several years. He realized he was happier as a developer and saw an opening on our team. On the surface, there was no reason to hire him. He hadn’t developed in years and was pretty rusty with his technical skills.

Since this was an internal candidate, I took him to lunch as a courtesy. In the course of the conversation, I was impressed with his work ethic, empathy for the challenges of management, and his strong customer-centric approach to software development. Late in the conversation, I told him flatly that I loved his attitude, but had concerns about his ability to develop after being out of it for many years.

He assured me he would spend his own time re-learning languages and environments. This was one of those “look a person in the eyes and judge whether he is sincere or not” moments. I judged him to be sincere. He went through the rest of the interview process, and we agreed to hire him, strictly on attitude. After all, how often do you get a chance to bring someone with management experience and a customer focus onto your development team?

Results? He became one of our most trusted developers. He won company awards and frequently was asked to personally address issues with top customer accounts. His attitude of self-motivation, customer focus, and results were the keys to his success. Yes – I could have hired a person with a couple years of programming experience that on paper would have “coded circles around him.” But the results would not have come close to what this person delivered in his years working for me.

Think about how you acquire talent. Do you engage candidates in meaning dialogue about learning, customers, and principles of software engineering?