The A-Team

Some things in life are just happy accidents. Sure, many of them include an element of hard work and determination, but having good things just fall into your lap doesn’t necessarily hurt, either. My first job out of college, technical support for a large printer manufacturer, led directly into my first job as a business analyst. I did a lot of hard work as a tech support agent, which led to the opportunity as a BA. The happy accident was the project to which I was assigned; the one that contained the best of the experienced analysts in the division. They were the ‘A-Team’ and I was able to sit and learn their techniques while I applied my experience as a business area representative. Had I not been assigned to that team, I never would have gained the solid foundation upon which my career currently rests.

Because of that experience, its always been a fascination of mine how it is that such a team of all-stars is assembled, and thus why this article in infoworld.com was so intriguing to me. It details the different cast of characters needed to make a special-ops team successful. Its no surprise to anyone who knows me that personnel #7 fits me like a glove. One of the things I’m known for is simply knowing a little bit about everything regarding the current state and future trends of technology. If you want to know what’s hot, you come to me. Chances are, I know about it and can tell you how it might impact business.

While the article did a good job of explaining the personalities needed for a successful team, it didn’t really go into the mechanics of how to go about assembling such a team. Being a member of first-line management, this isn’t something I’ve ever been able to go and do. My team, and a great team they are; one I wouldn’t trade away, came preassembled, but someone definitely spent some time developing and selecting quality people. One day I do hope to be given the opportunity to assemble an A-Team, and here is how I intend to go about it.

First, as with most things, the need for such a team must be recognized and sanctioned by the stakeholders. The problem will need to be something that no existing team can manage on their own or the problem domain is one which is unfamiliar to any existing team. Just as the infoworld.com article states, having 'air support’ in upper management is critical.

Second, the need or opportunity must be of great importance. You don’t assemble a team of all-stars to figure out a better way to clean the company bathrooms. Forming such a team as this by drawing the best from each of the business units create a brain-drain in the impacted teams. That’s not necessarily a bad thing, as other team members will be forced to either pick up the slack or let the department fail; both outcomes are learning events which can help to grow team members. This is still a risk and one that should not be undertaken lightly.

Alternatively, you can hire new team members for your A-Team to avoid a brain-drain. Beyond the additional headcount which your business will need to absorb, you’ll also have existing team members question why they were not promoted to the new team and why these new team members are better than ones who have been there for a long time and know the company and existing business. Once again, this is not necessarily a bad situation, but one that must be considered when putting together the team.

Once you have all the right team members, you need to match up the tasks in front of you with the skills, knowledge and passions of the team members. As the book Good to Great said so well, you need to know which people are in which seats on the bus. Placing someone who doesn’t have the skill, knowledge or desire for certain tasks in a role where those same tasks are the primary function will not necessarily lead to disaster, but it will frustrate your resource and likely yourself.

Even with an A-team, its unlikely you’re going to have an expert in each of the areas you need covered, so at least someone will end up doing tasks with which they are not comfortable or would rather not do. This is a part of life in projects.

The biggest hurdle in keeping the bus headed in the right direction seems to me to be communication. That first project of mine, we had relatively few limits on resources, both people and budgetary, yet so many of the problems we encountered led back to missing hand-offs between the different functional divides. Even A-Team employees can get caught up in their own area and forget to collaborate when they reach a touchpoint with another team member.

One solution, the one which the team I worked for requested, was more general status update meetings in order to improve communication. This is one way in which we were not an A-Team. Status update meetings are fine for high-level overviews, but do little to facilitate the low-level collaboration that must occur if you’re planning on creating a useful, cross-discipline solution. Our failure on that project was in not spending enough time with each other in discussion about how the different areas would collaborate once the solution was in place. I lost track of the number of times that we built bridges to nowhere because the other analysts did not realize they had to catch a process hand-off.

So who would be in your A-Team? How would you run it?