Will Crew or Military Models(for team formation) work in Software Development Projects?

Posted on Updated on

Dave Snowden in his address on Social Computing & KM during the KM India summit brought about a point on how current organizational structures are not suited for creating social networks and hinder performance. Dave explained this with the Matrix Organizational Structure where people have multiple reporting relationships and no one is sure which way their loyalties should be.

Dave talked about the “Crew or Military Model” of team formation which he termed as more adaptive in nature based on the concepts of  “Role” & “Expectation of role”. He explained this with an example of how teams are formed in airlines or ships. People who may or may not have worked before come together to form a team and work as a team based on an understanding of what each persons role is and what to expect from that role.

In the IT industry this model, in intent, is a model that most software development organizations ‘aspire’ to implement while creating teams for developing software. I believe that in theory this is a good concept but there are several questions that need to answered and various soft aspects thought.

  • “Crew” model would work for teams where the tasks are repeatable, tasks which have little room for variation and have to be done “the same as before way” on time. Tasks which have the procedures defined and the job of the person doing is to just follow the procedures and do it.   For example;  airline crew. pilot, co-pilot, air hostess, stewards, checkin counter assistants. The kind of tasks involved are routine, repeatable, well documented, and need to be performed with precision every time.
  • In the software industry, for example each development project is unique and the development life-cycle is ‘not predictable‘ to say the least.  To compound matters, skills required may not be available and training may have to done while on the job. This is not the case in crew model where almost all the times things are predictable and follow a predictable sequence.  For example, in an airplane you can predict what would happen from the time you take a boarding pass and go to your seat to the time you get down from the flight. It is all very very predictable, linear & sequential. There is no room for variation — unless it is a private chartered russian flight 🙂
  • Though one may say that even in software development we have roles like PM, Technical Leads, DBA’s etc etc and we know what is expected of that role. However, the reality is that software development is an iterative, some what chaotic, emergent process. There is a complex interplay between all stake holders to create the ‘intangible’ software that people want. Now by very nature of their business, airlines/ships can’t have an iterative, some what chaotic, emergent process to the nature of work that teams do there. Imagine a team of  air hostess emulating an iterative, some what chaotic, emergent process to serve the passengers.!!!
  • Another important element is the “customer engagement” in the whole development life-cycle itself where requirements are fluid and can keep changing. Now one could argue that even in a ship or a airplane there is engagement required with the customers, but that engagement and the choices available and hence the options that the crew can exercise are from a limited set that is almost well known in advance.  It would be only in an adverse situation of a ship capsizing or a plane mishap (e.g. hi-jack) that the engagement model between all the participants becomes fluid and relatively unknown.
  • The most important aspect I feel is the “nature of work” itself.  By very nature, software engineering calls for continuous learning & updation of skills while on the job. This is not necessarily true for airline or ship teams. Not to say that they don’t need to learn or improve their skills but that is within a very narrow band and at a slow pace than in software engineering. This aspect leads to totally different  behavioral, motivational, aspirational & emotional factors within individuals that then influence people, teams & how they work.
  • I also think that teams in crew models the teams need to “coordinate” with each other to perform the task whereas in software development teams need to “collaborate” with each other to perform the task. These two things may look similar but call for totally different actions, engagement models within teams.

The above are just some of the many questions out there. What do you think?

Would ‘Crew or Military’ models of team formation work effectively in software developments? What could be other challenges and opportunities?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s