Team Structure - F1 Style

What?

OK, it sounds a bit daft, and you might think that my interest in motor sport has addled my brain into thinking my job is in any way related to working in a Formula One team. But just bear with me, its not quite as stupid as it first sounds...

Team Principle

For a Formula One team, there is one simple objective, and that is to develop and hone a driver and car combination that can go faster than its competitors. Although the objective may be simple, the recipe for success is incredibly complex. There are so many elements that have to be brought together to achieve success, and so many different approaches that can be adopted that the primary aim can easily get lost in a mire of complexity. To have any hope of success, the team have to have a common vision and to have that vision instilled in them by someone that they respect, and who has the ability to motivate them. In an F1 team, this is the Team Principle.

Technical Director

The Team Principle has the vision and provides the team with motivation and focus, but doesn't necessarily have the necessary skills to implement that vision in a highly technical arena. Therefore every team has a Technical Director. This is a highly experienced Engineer, who also has excellent management and communication skills. It is his job to take overall responsibility for the design of the car, and to ensure that the various aspects of the car's design all work together to provide the best overall solution. This is an absolutely critical role, because the Technical Director is the one who fully understands the overall technical solution.

Engine Department

If you told your Engine Department to produce the optimal solution, then they would probably go and build a 6 litre, turbo-charged V12 which would produce 3000bhp. They would have figures that would prove beyond doubt that this is the perfect engine, taking into account power, torque and reliability. However, a car built around such an engine would be slow, as it wouldn't go round corners and it would be extremely heavy. Brilliant technical minds tend to forget simple things like this when left to their own devices.

Aerodynamics Department

The Aerodynamics department would build you a beautiful car with a drag co-efficient approaching zero and enough downforce to stick it to the ceiling. However, the driver might be lying down to such a degree that he couldn't drive the car effectively (Brabham '86) or he might not be able to fit in it at all (McLaren '95).

Optimised Overall Solution

You get the picture. Each area is so complex in its own right, that it needs experts in the field working in a dedicated team to provide solutions. However, they will always think that their area is the most important, and therefore optimise their solution to the detriment of the overall package. There needs to be one person who can make the decisions to ensure that the right compromises are reached so that the overall package fulfils the overriding objective: to make the car faster than its competitors.
An example of this sort of decision would be to demand that the engine can run at very high temperatures, so that the radiators that cool the engine can be smaller. Although this doesn't help the engine in any way, it allows the aerodynamics to be improved without compromising in any other area, making the car faster.

Developing IT Solutions

The problems faced by IT organisations are very similar, in that the aim is to provide an extremely complex solution to a fairly simple problem. To stop the complexity and specific areas of expertise taking over, the team (or teams) need a very clear vision to keep them focused. This visionary would probably be the CEO or CIO.
They also need someone to take that vision and understand how to turn it into a technical reality, albeit from a fairly high level. F1 teams call this person the Technical Director - but what is the equivalent role in IT? Each project team needs to be given technical direction and guidance to ensure that their contribution to the solution is consistent with the overall technical vision.

Architecture Gone AWOL

It is interesting to note that this role is rarely apparent in IT organisations. It should really be Architecture that have this sort of control over what is being built, but Architecture tends to sit in its Ivory Tower drawing diagrams and looking at the future direction of the company's technical infrastructure. It is rare that they think that they should have to get their hands dirty and get involved with creating today's solutions. I think this is a really important role, and one that must be filled by an extremely capable technical person who also has great management skills, not a people manager.

Technical Specialists

One difference in IT is that skills can be more transferable. The same person might be equally valuable in writing ASP.NET pages or Web Services. However, experience tells me that dividing your organisation into skills-based teams never works by itself.

How to Organise Your Organisation?

Skills-based teams don't really work. Organising your organisation into teams based on infrastructure (DB, Services, Website) isn't usually that effective either. Cross-skilled project teams seem to work best, but then you tend to get Project Orientated Architecture.

Balance

The solution that I think works the most effectively is a combination of these. You need to have pools of people with certain skills to ensure that you can develop all your systems effectively. These people don't need to sit together, or even work together, but you need to know who can do what and what training requirements they have. You need project teams to drive the business value into your technical solutions, and to provide communication, momentum, motivation and team spirit. These cross skilled teams can be assembled for a given project, and should ideally sit with each other and a business representative who is driving the project.

Governance

You also need to have governance of the various areas of your infrastructure, to ensure that you avoid Project Orientated Architecture. This needs an Architecture that is actively involved in today's projects, including a Technical Director and Architects responsible for each area of the system, providing governance and guidance. These need to balance each other; if one becomes too dominant then it won't work. If projects dominate, you will screw your architecture and future delivery capability. If Architecture dominate, you'll never deliver business value. If skills dominate, you will lose team spirit and motivation, communication will suffer and you will end up with sub-cultures and an us-and-them attitude.