Having taken stock in your team’s current skill levels from part 1 of this series, it’s time to think for a minute about what your ideal team could look like. What do you think? Should they all be rock stars? Everyone would instantly gel and become best friends, you’d meet all your deadlines, and your application would scream. The proverbial dream team.

There are reasons that dream might turn into a nightmare. I’m going to challenge the notion that you need a team of experts to build software in this new economy. Here are my arguments:

Conflict avoidance. You may end up with too many cooks if you’re not careful. Cast your memory back to the last time there was a heated argument in your team. Chances are the participants were at about the same skill level. The fiercest technical arguments I’ve seen have taken place between team members who were equally matched in the same skill. Resolution was slow if ever and resentment ran high for the loser. It was incredibly disruptive. Wouldn’t it make more sense to have a team with staggered skill levels? The more experienced team member should always be able to resolve a conflict with junior teammates. Notice I said resolve, not win. The more highly skilled team members should be strong enough to win an argument in favor of their solution or be able to recognize the merits of an alternative and accept it as a better approach.

Morale. Not every task on a project will have the same difficulty. Someone’s got to write the reporting modules and installation scripts. Tasks that challenge a novice or advanced beginner will drive more highly skilled members to boredom. If task assignments are blown, you’ll find your team members surfing the net instead of deeply engaged in their work. This will negatively impact overall project productivity.

Upward mobility and growth. How can we distinguish ourselves from our peers if we’re all doing the same work at the same level? It’s a proverbial cat fight with everyone trying to out do their team mates for recognition. The result is an environment where it’s extremely difficult to shine and just as importantly, difficult for leaders to identify the superstars who are increasing in skill. We all assume that we’ll get a merit pay increase every year but at some point we will hit the salary ceiling within our industry. When this happens there are three paths: hover near the ceiling and hope to get a “market” adjustment every few years, move to another role within the company with a higher salary base, or move on to a new company willing to pay a premium for your skills.  None of these choices is good for team stability.

Cost to your employer. Ask yourself this question: If it was your money, would you keep a team of experts on staff if you didn’t need to? Businesses live and die by optimizing costs in order to maximize profit. From a business perspective, if a company is paying more than the market rate for a particular service or skill they’re paying too much. Certainly more than their competitors are willing to pay. That’s money that could have been allocated elsewhere – training, new equipment, bonuses, or profit. Employment is a contractual agreement that carries with it an obligation to provide an employer with an appropriate return on investment for the salary being paid.

So what’s a good blend of skill levels to make sure everyone benefits? Skill level mismatches on a team are essential and you need a balanced distribution to have a healthy team.

I want to show a suggested distribution adapted from Andy Hunt’s Pragmatic Thinking. There are no exact numbers, It’s meant to more for guidance that hard analysis. Andy uses this diagram to describe the population of all developers in the industry with a particular skill. Notice that it’s a non-linear distribution and weighted towards lower skill levels.

I think it makes a good model for team lineups as well and provides an excellent cost-to-benefit ratio. Your expert and proficient members would make up no more than 10-15% of your team. Your company will pay a premium for them, but their higher skill levels will provide the bulk of the productivity on projects and also provide leadership and oversight while your junior members grow into their roles.

What’s the best course of action if you find yourself with an unbalanced team? Look for opportunities to rebalance at the conclusion of projects or major milestones to minimize disruption. If you find yourself with team members with matched skill levels on the same skills, consider breaking your team into sub teams or spinning off separate projects and readjusting the lineups. This is going to be a continuous effort and you’ll see gradual improvements along the way. They key is to avoid combining equivalent skill levels working on the similar tasks on the same team.

Building strong teams has always been important to me. Over the years I’ve had successes and failures and spent a lot of time reflecting on the ins and outs of attracting, motivating, and growing talented developers. Major influences in my thinking have come from Joel Spolsky (Smart and Gets Things Done)  and George Leonard (Mastery), Marcus Buckingham (First, Break All The Rules), and most recently Andy Hunt (Pragmatic Thinking & Learning).

In Pragmatic Thinking & Learning, Andy Hunt provides an overview of the Dreyfus Model of Skill Acquisition. The Dreyfus model is a cross disciplinary study of technical people and their skill levels. The results of the study call out specific skill levels and identify the characteristics of people at each level. I’ve listed some highlights below and bolded the characteristic that I think best exemplifies someone at a particular level:

Novice – “Just tell me what you want me to do.”

• rigid adherence to rules
• no discretional judgment
• does not feel or accept responsibility for outcomes

Advanced Beginner – “I’m ready for my next task.”

• lacks perception of big picture or larger context is seen as irrelevant,
• all situations are treated with equal priority.
• still does not feel responsible for outcomes
• rules can be applied situationally

Competent – “I’ll have it done by the end of the day.”

• still follows rules but begins to encounter and cope with crowding and conflicts (multiple activities, information, rules)
• begins to explore the reasoning behind rules
• sees actions as part of larger, long term goals
• forms deliberate, organized plans
• feeling of responsibility begins to arise from active decision making

According to the Dreyfus study, most people don’t get beyond Competent at most skills. There’s just no need or not enough challenge in a particular activity once our goals are met. To go beyond this level requires dedication and concerted effort to get better. In other words, it’s time to go pro!

Proficient - “The XYZ pattern can solve that problem perfectly.”

• can distinguish important elements of a situation and ignore irrelevant details
• can learn from the experience of others (e.g. case studies)
• uses pattern recognition and past experience to identify a problem and maxims (as opposed to rules) to solve them
• intuition begins to take over for rules

Expert (aka Master or Wizard) - “Did you need anything else?”

• no longer reliant upon rules, pattern recognition and maxims are baked-in
• can formulate possible outcomes and future visions of what is possible
• can very quickly establish an intuitive grasp the situation and solve problems seemingly without effort

I’ve quickly come to love this model for its clarity. It cleanly describes the increasing scope of awareness and how experience gets baked into our consciousness. It provides a discrete set of criteria upon which to assess the current skill set of our teams and more importantly, it’s actionable. We can plot the next steps to our team improve and grow.

If you’re involved in decisions related to team management it behooves you to take a moment to asses your team members and build a quick skill level inventory based on the criteria above. Based on that inventory you can begin taking action. Stay tuned for part 2 where I will share some thoughts on optimizing the team lineup.

Last week, a noted analyst from the Burton Group wrote a blog posting declaring SOA dead. It's a flashy headline and she does have some interesting observations but fails to identify any lessons learned and actionable next steps. It's crucial analysis that I've come to expect from the Burton and Gartner groups but didn't see it there.

When it comes to analyzing technology trends, there are two adoption models that I look to: the technology adoption lifecycle (TAL) and the hype cycle (HC). Most consumable products entered into a market (e.g. walkmans, playstations, ipods) follow the TAL model where a product is introduced, hits a critical mass of consumers, and slowly sunsets to be replaced by a newer, more advanced technology. When it comes to consumables, we devour and move on. Conceptual ideas, trends and behaviors (e.g. word processing, object-oriented programming, social engineering), however, tend to follow the HC model more closely. With higher level concepts, our brains need to noodle on them - learn and improve and iterate, potentially through many TAL cycles if tools can help us. We slow down once we get to the point where we've improved our mental model and have achieved a higher level of understanding that is beneficial to our survival.

To me SOA is following a classic hype cycle. There was a period of intense interest and excitement and the promise of a new world order. Vendors swooped in and built (overly) complex solutions with impressive architectures to solve huge enterprisey IT needs and then wrapped a bunch of MBA technobabble around it and sold it to unspecting CIOs and CTOs. I mean, it DID look good on paper. The brochures had bullet points to cover all of our IT needs and wants. But what followed was a severe period of disappointment as the products failed to live up to their expectation. We learned a tremendous amount about why this happened which is why I believe we are very much into the Slope of Enlightment right now and heading towards a path of productivity and success.

My good friend, Denny Boynton has written a spectacular autopsy report on SOA's demise, what we learned from it, and where we're going from here. I highly recommend you check it out if you are involved in building enterprise software using web services at your company.