Many IT organizations compare themselves to sports teams, yet where are the coaching staff, pre-season, training camp, game-plans and regularly scheduled practices? If practice in a safe environment under the supervision of coaches is how you get better at a skill, and essential for team success, how come our IT team never practices anything at all?
To answer these questions, I am going to do a quick compare & contrast. Part 1 will perform a quick compare & contrast, while Part 2 will focus on a root-cause analysis & make some (im)modest suggestions.
Front Office: There are, of course, executives and money guys above both professional sports teams and corporations with significant IT organizations. Each has a general manager or CEO who is (usually) an expert in their respective business, and who makes key financial decisions while trying to create & execute a winning strategy.
In professional sports, though, the general manager's decisions are largely (in consultation with the coaching staff and owners) about whom to hire, fire, trade, draft, and pay to build a great team. Note that these activities are largely operational and inward-facing. In larger corporations, most CEOs, have a primarily outward-facing role that leaves daily operations to the C-level executives.
Head Coach: Sports teams have a head coach, who determines strategy, and who hires a coaching staff with expertise in particular skills or aspects of the game. Sports strategy is an attempt to optimize your wins based on the skills & strengths of your team compared with your opponents (see for example the excellent Moneyball). Coaches develop game plans consistent with the strategy to optimize their chances of winning against particular opponents; unless, of course, you are the Oakland Raiders (sorry, had to get that out of my system).
IT doesn't have a head coach; IT has a CIO, who is largely concerned with how much money to invest in on-going operations vs new projects within parameters set by the CFO. IT strategy is usually based on recommendations from a CTO, and the game plan for winning in a particular market is usually developed by the CMO. A CIO implements a strategy and participates in a competitive game-plan, but the CIO is usually only directly responsible for the methodology used to build and operate products or services. Aside from referring to "my team", CIO's spend precious little time, much less investment, on human capital and organizational development issues.
A CIO, therefore, is more like a member of the coaching staff, a coach whose specialty is IT. But that should not explain or excuse the lack of teamwork. A complex software development or systems project requires sophisticated business processes to keep its many participants in sync. For example, a full-blown Rational Unified Method (RUP) project uses a business process that includes dozens of roles, capabilities, and standard activities, and that's just the generic, top-level complexity of RUP. When we incorporate the technical specifics, organizational peculiarities and iteration goals (prototype, pilot, production, etc.) that are part of any project's unique characteristics, task plans in the thousands are not unusual.
Yet you rarely hear of IT organizations practicing their methodology to achieve optimal performance. IT seems to be the only "sport" where we expect coaches, the newly drafted and the veteran alike to run out onto the field of play and somehow know the entire strategy, playbook, competition, and assignments, and then perform with optimal productivity, all without ever having so much as a scrimmage together.
Players: Athletes at the professional level have great natural physical ability, and are also highly skilled in their discipline (quarterback, linebacker, etc.), having honed those skills over many thousands of hours of practice and hundreds of games. But athletes are not necessarily effective at using those skills effectively to implement a strategy or game plan, or to coordinate or communicate their tasks in real-time. For all these reasons, coaching is essential to team sports.
IT professionals are usually highly intelligent, which is their physical ability. The IT labor market is also diverse, and its players do not always work for the same company, or reside in the same locality or country, even if they are playing on the same "team". As in team sports, maybe even more so, IT professionals are not necessarily effective at using their skills effectively to implement a game/project plan or strategy, so coordination and communications is still essential.
Recruitment & Draft: Team sport skills are highly measurable via standards such as speed of acceleration, muscle strength, endurance, ability to memorize plays, etc. A player's disciple skills are also visually apparent as seen in game play, whether live or on video. Recruitment is largely an activity for college coaches who identify players with natural abilities that they can subsequently develop through coaching, turning them into running backs, linebackers, etc. At the professional level, players in particular disciplines are readily scored by the teams doing the hiring, are evaluated against a team's needs, and then selected in the draft.
Within IT, college recruitment is mostly on the basis of standardized test scores, not demonstrable skills. There is a seemingly eternal dialog in academic computer science about what to actually teach students, but the study of theory usually completely submerges actual practice, and what practice there is focuses on only one discipline (e.g., coding). Undergraduate test taking, not game-time, is what determines academic ranking.
The equivalent of the draft in IT is hiring, and, In comparison to sports, evaluating IT skills is actually quite difficult. The skills within IT disciplines (coding, testing, documenting, designing, etc.) are surprisingly and alarmingly unpracticed and un-measurable except on-the-job during actual projects. Because job experience is the only practice we get in IT, it is not even obvious that recruiting computer science majors is the best strategy. And IT job experience tends to be highly unique to the company where it occurred.
Training: Becoming a professional athlete is largely about the training. Some skills can be developed through individual study and training, but the direction, measurement and evaluation of an experienced coach is usually essential to achieve the highest individual level within a team context. All team sports have developed extensive & focused regimes of training & practices appropriate for an entire season and particular game.
In comparison, becoming an IT professional is largely about convincing someone to hire you in the first place, since practice is only to be had during projects, and for most practitioners, the only games being played are the ones you are paid to play in.
We all know that training in IT departments is grudgingly provided, and then only for the basic skills necessary to use some new tool. "Team training" usually means "the whole team was trained on a tool", not that anyone learned how to work together effectively.
Projects (i.e., IT games), at least, do have project managers, and IT project plans are comparable to a game plan in sports. But we never actually scrimmage or practice the game plan before we hit the field.
Coaching Staff & Game Management: Sports are generally fast, real-time events, and the coaches are in constant communication, selecting the plays, evaluating the results, providing feedback to the players, before, during and after the game.
IT projects, in comparison, rarely have someone in the role of head coach with a coaching staff. Instead, coaching responsibilities are usually distributed over project managers, development managers, test managers, operations managers, product managers, etc. Worse, within the typical corporate matrix, each of these coaches reports to a different boss with no common technique or methodology. Rather than provide feedback before, during and after a game, IT employees usually get feedback only once a year during annual performance reviews.
IT projects are not typically real-time events (outside of some operational situations), but most IT projects have only the most rudimentary tools for evaluating results. Typically, project managers only know if particular "plays" (i.e., tasks on the project plan) were completed, not whether they were successful. My guess is that because IT lives with failure so much, that is the reason post-project evaluations came to be called "post-mortems".
Summary: As we can see, IT does in fact share many of the traits of a sports team, and would logically benefit from coaching & practice. But this is certainly not the case.
In part 2, I'll explore why I think the IT industry behaves as it does, and also why I think we can learn a thing or two by behaving more like a professional sports team.