Will Crew or Military Models(for team formation) work in Software Development Projects?
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?
Does Knowledge Management need the KM Function to be successful
Does an organization need a dedicated and separate KM function in order for it to do KM?
If one looks at great organizations like Google, Apple Yahoo (who are considered to be great Knowledge led organizations), they don’t have dedicated KM functions. What’s important is that the basic tenets, ethos and culture of KM needs to be part of the organizations ‘being’, the way of life — akin to the breathing process, doing it continuously without even realizing it.
All the above organizations (and many more) are role models in the knowledge era. The great thing about these organizations create processes & structures that truly embody the spirit of the ‘needs’ of the knowledge worker and through that they are able to attract the best talent and provide them with an environment that goes to the core of what knowledge management espouses. They don’t do KM for the sake of KM and saying ‘oh, we also do KM and realize the importance of it and hence we have dozens of knowledge managers supporting KM’…
I personally believe in the approach taken by the Google, Apple Yahoo type organizations as an effective way of doing KM.
For the ‘regular’ organizations I believe that creating a dedicated KM function is a good thing to bring ‘focus’ on KM and giving it legitimacy. This will send the right signals and help get going.
However, for KM to be truly effective in those organizations, over a period of time, the KM function should strive for enabling the different parts of the organizations to do KM themselves and not rely on the KM function. This is where KM needs to be part of the organizations ‘being’, the way of life. This should be the role and end goal of CKO’s and they should also be measured on this aspect. Once the above has started to happen (and this should happen in a measurable/definite time frame) then the KM function should be considered for dissolution and the charter of the KM function should become to just oversee it’s disbanding
The above may look good in theory but there are practical challenges like (just some of the many…):
- Over a period of time the person leading the KM function can get attached to it and can find it difficult to let go.
- KM has overlap with almost all functions and in the beginning there is less conflict and at a conceptual level people agree for KM to work on the areas of overlap and make progress. As clarity emerges and overlap areas gain traction, the different functions start voicing or thinking about what do these overlaps mean and start questioning this.
- This creates ground for small battles in bigger organizational ‘turf wars’ and results in various functions/departments further entrenching in their beliefs/positions and the organization opting for ’status quo’ approach to please all.
It’s sad but a true mirage and we continue to rely on “Knowledge Management needing the KM Function to be successful” approach…
After Action Reviews[AAR] in software development
AAR’s is a process used by the US Army where after each action [in army's parlance] the team meets to capture the learning’s and lessons, what went well and what could be done better. The advantage of such AAR’s is that the activity performed is fresh in the teams mindspace and they can reflect better on the activity performed and learn from it.
Variations of AAR have been used in the software industry(and in other industries also) in form of Post Harvests, Sunset Reviews, Post Mortem Report etc where the team meets at the end of the project, to look back and reflect on what went well, what could be improved and how to gain from the experience.
While all such practices are fine in theory, there are some fundamental issues in their execution. Few of the limitations are:
- Projects, programs etc get executed over a long span of time – maybe months, years. If a post harvest, sunset review etc is conducted at the end of several months, then it is practically impossible for teams to remember what went well and what could have been better. These meetings then usually will turn into blame game, finger pointing, or of things at a very superficial level. The real learning’s may not surface in such scenarios.
- The importance if learning’s, lessons may become trivial. When the team of individual is facing an issue, or trying to solve a problem, then the lessons they learn while solving the issue/problem the first time is the most important. The next time they face the same situation/problem, then they will see little value in the lessons. They already know how to do it and over a period of time, by the time the post harvest, sunset review happens, the very important lesson that the team had while solving the problem could have become trivial to even mention it.
- Team members join and exit the projects/programs throughout the life cycle of the projects/programs (This is especially true of software development projects). This is compounded by the fact that people leave or join a project not in one shot but in a staggered manner over a period of time. Post harvest, sunset review do not account for tapping into the lessons learnt by people leaving the project, nor do they try to tap into the lessons that people joining a project/program midway bring with them.
- Many times during Post harvests, sunset reviews etc, the team members who had left the project and are now part of other teams are asked to join for such meeting. The intent is very noble — to also tap into the learning’s that these people had and benefit from it. However, the problem is that these team members who had left the project are mentally NOT associated with their previous project anymore, they are mentally switched off from their previous project and are very unlikely to contribute any meaningful learning’s or lessons, and even if they do, it will be very superficial. NOTE: It is not that they have noting to contribute, but the very fact they are mentally, emotionally and physically removed and no longer part of the project, make it difficult from these people to contribute anything meaningful.
There is no doubt that learning’s from Post harvests, sunset reviews can be applied to new projects, but the very fact that lessons/learning’s of AAR’s can be applied right away in the next activity of the current project make it very powerful.
It’s about time that the software industry looks real hard at the value it derives from Post Harvest processes.
Relationship of KM with other functions in an organization
After working in the KM arena for many years now, one thought has started puzzling me — “The relationship of KM function with other functions in an organization and the consequences of these relationships — in terms of the KM viewpoint & outlook, success etc.”
I have observed many different Indian IT organizations [I presume it must be similar in other countries also], that each organization has it’s own structure for KM within the organization. For example in one organization, KM reports into quality and is part of the quality function, In another organization KM reports in Education, Training & Research, In another it is heavily distributed and some parts report into Marketing & Sales, some into HR etc. In another one we have a separate KM function that reports directly to the COO.
I have observed the KM initiatives in all these above organizations from close quarters, through various interactions and in all of these cases, the results of KM and the road map, the view of KM, what KM is, is all different and very heavily influenced by the function/person KM reports into.
- KM being a cross-functional discipline, also is similar to an elephant being viewed by blind-folded persons and each person [function] having it’s own view/perception of the elephant [KM] depending on what part of the elephant they are seeing.
- At the same time, KM’s cross-disciplinary nature can create structural tensions within an organization if it is a separate function, with developing working relationships, alignment on directions, strategy, over stepping on other functions toes.. being just some of the issues..
- KM being a relatively new discipline and not very well understood by the stakeholders also contributes to this dilemma. For example, Quality as a function has been there for ages and is pretty well understood. You will very very rarely see quality reporting to say CIO or HR or Marketing or Learning/Training function..
- Also, KM itself is a journey within an organization and goes through various stages.. from repository/technical platforms [CIO function alignment] to communities [HR/Learning function alignment ] to reuse of knowledge [Quality function alignment] to deep integration within the line function [function head alignment] to complex change management & Innovation [COO/CEO alignment]
Surprising isn’t it? We are in the knowledge era and the position of KM function within the organization structure is neither well understood or defined….
I think every organization that is starting a KM journey needs to ponder over this in great depth and align KM function appropriately within it’s organizational structure








leave a comment