November 2005
Vol. 3, No. 5
This newsletter is a basic HTML file, giving you control over the appearance through your Web browser's options and window controls.
From the Editor: One of my daydreams is to get a Ph.D. in organizational behavior. From what I understand, when entering these programs you eventually have to come up with one or more "research questions"" that guide your elective courses, research work, and dissertation. I already know mine:
Why don't managers use proven best practices for people management?
I have a lot of theories. Here's a paragraph of them: Today's top managers came up in traditional command-and-control hierarchies and therefore manage the way they were managed. Human resources professionals have only in recent years begun to understand how and why to translate HR practices into financial terms for upper managers. It is easier to track and measure things than people. When you are busy firefighting all the time, it is very difficult to take time out for fire prevention. Successful managers are those that "get things done," so these folks prefer to jump in and create any sort of tangible results rather than delaying the process long enough to plan the most cost-effective way to achieve it. Middle managers tend to get their positions for their technical skills instead of their people skills for many of the reasons listed above, and do not receive the extensive and ongoing training/coaching needed to turn them into effective managers, for the same reasons.
Then there's the "Peter Principle," which says people in hierarchies "tend to rise to the level of their incompetence." The classic example is the mistake of pulling a top sales person out of the ranks to run the sales organization, only to see sales sink because he or she does not have management skills and the sales force just lost its top producer. I won't even go into the many less-kind explanations I hear all the time from line workers and low-level managers. Although those are sometimes true, just as most line-worker performance problems are really system or process problems, the same is true for middle-management failures.
Even so, I believe each human is responsible for their own actions within the boundaries life gives all of us. I have trained successful self-directed work teams with zero upper-level support. All it took was a team manager who saw the value and trusted that he or she had hired good people. I also believe not only that teamwork is a way out of most of the problems your team faces and/or to better financial performance, empowered teamwork is the most ethical way to run most work groups. Out of responsibility to your financial obligations to the company and ethical obligations to your workers and/or colleagues, you should seriously think about changing or optimizing your teamwork.
Most human beings, myself included, would rather find a reason not to do extra work than make an investment in a better working life for themselves and those around them on the job. But when you look deeply into those reasons, they always start to look a lot like excuses. So if you're a manager at any level of your company, with two employees or 20,000, here is the question I propose to you in relation to my research question above:
What's your excuse?
If you know you can do better as a manager or a team—and who can't?—contact me today to find out how.
Article: Most software development (SD) projects fail by at least one of the standards of project management—scope, schedule, or costs. After looking at many studies on the subject, Jason Pattit and David Wilemon of the management school at Syracuse Univ. (USA) report that 25% of SD project are cancelled outright. Among those completed, 80% of the budget is spent fixing bugs. Around 30% end up with runaway costs. The major reasons for these failures, Pattit and Wilemon write, are:
The key point is that "product and tools-related reasons…comprise only one-third of all of the reasons for overruns and delays…" The primary causes are "organizational, managerial, and human aspects" of the project (that is, people problems). The authors go on to describe a number of best practices "identified through an extensive review of the literature on managing SD efforts, and the personal experiences of the authors working with and observing several SD teams." The list is too extensive to adequately cover in this newsletter, but here are the main categories:
To help software project managers determine whether they are doing everything they could, Pattit and Wilemon have created a questionnaire assessing the use of customer input, support of senior management, quality of the SD process, project success, and team members and leaders. Another is designed to help senior managers develop a "software development team culture" that accounts for the perceived needs of individualistic developers while still capturing the benefits of teamwork.
The authors also emphasize the importance of using the lessons of one project to improve later projects within the firm. This goes well beyond the limited learning that occurs during the code-and-fix cycle, and it requires various approaches. They suggest reviews of the entire project with senior managers, internal users, support groups, and steering committees. Delegating authority downward in the team "will not only encourage individual learning, but also can remove obstacles that block the flow of information within an organization." Successful firms have ways to capture previous lessons learned and change they way they perform future projects as a result.
Many elements of formal software development processes are drawn from project management, and the article used the term "the project manager" throughout. But it did not specifically call for the use of PM techniques, so I e-mailed the authors. "In general, smaller projects with more exploratory goals requiring radical changes are typically less amenable to formal PM techniques," Wilemon responded. He and Pattit also do not assume that one individual will lead the project, and he listed a range of job titles they have seen filling the role. Although they do not emphasize PM, he wrote, "we have seen that using PM techniques to coordinate an overall program can be advantageous, specifically in regards to coordinating individual project teams that are part of the program, and integrating the output from each team into the final software/hardware product."
Application: I admit being flummoxed by software firms that think empowered teamwork and formal project control won't work in software projects. The typical argument is that software work is too "creative" or developers are "lone wolves." And yet, there is a fairly well-defined development process for putting on a stage performance that most arts companies I've worked with have followed to some degree. You can't tell me that developing software products is more creative than putting on a show. Having done backstage work as my first career, you also cannot tell me that programmers are more intent on expressing their individuality than are actors. But directors, choreographers and conductors hammer constantly on the need for people to collaborate closely to improve each other's performances and thus the production as well.
If you are in a typical SD company, your managers declare a project successful as long as it eventually produces a deliverable. Period. To my experience, although there is plenty of griping and stress during the project, after it's done everyone takes their celebratory day at the video arcade and moves onto the next project confident that "things will go better next time" even though no attempt has been made to ensure that happens. Rarely does a lesson-learned exercise, if held at all, capture in detail what went wrong, create action items, and make sure they change the way the next project is done. Along those lines, I hope more research will be done comparing similar projects that do and do not use formal project management on top of formal development processes. The projects I have been involved with, even the "bleeding edge" ones, would clearly have benefited from PM, but then they also did not closely conform to established development frameworks.
If you're a software team leader or member, where can you start? Ask for a meeting with the "powers-that-be" at your organization, show them the statistics at the start of this study summary, and try to get them to invest in a formal development process. If your company already uses one, or you can't convince them to do so, find a copy of the article and run through the assessment it includes (check the Internet or your local college business library—see "Sources" below). Then start applying what best practices you can that do not need upper-level sign-off, like pairing more- and less-experienced developers for peer reviews. One change at a time is fine, and you don't have to make a big deal about it. Just say you want to try the action, make it happen, and capture the results of your experiment to improve the next go-around.
Sources: Pattit, J., and D. Wilemon (05), "Creating High-Performing Software Development Teams," R&D Management 35(4):375; e-mail attachment from David Wilemon to the editor, 10/31/05.
Article: One positive result of the recent corporate scandals in America is a renewed focus on the role of ethics in business. But business academicians have long been looking into what defines ethical behavior by corporations and the effects, including financial ones, of failing to live up to those standards. One key measure they use is "corporate social performance," which refers to the results of a company's policies and programs related to getting along with society—not all that different from looking at what an individual does to act ethically. This theory focuses on stakeholders who are most directly affected, such as shareholders and customers, but business professor Harry Van Buren of the Univ. of Northern Iowa argues that another set of stakeholders is often overlooked: employees. In particular, Van Buren discusses two ethical principles that could apply to any stakeholder and talks about them in terms of this group that is the business. (Both of these principles have shown up in studies reported in TeamResearch News, which is how this article relates to teamwork.)
Van Buren writes, "Recent research in the area of work-family programs, for example, has concluded that merely making…programs like flex-time fails to address managerial resistance to them, which directly affects the likelihood that employees will actually take advantage of such programs." The mere existence of the program is not a good measure of the firm's social performance toward its workers. In fact, the full model of corporate social performance starts by looking at the firm's stated or assumed ethical principals and goes on to look at how (and if) those principals affect company processes, as well as the results of those processes.
Van Buren says that stakeholders play three important roles in judging social performance: setting up expectations about right and wrong business actions; being affected by the outcomes of a firm's social performance; and evaluating the firm on that performance. Obviously, employees do each of those things. The two principles mentioned earlier are "distributive justice," basically how a company shares its gains, and "procedural fairness," the right stakeholders have to a voice in a company's policies. In both cases, ethical concerns suggest that the worker should get rewards and influence based on how much they contribute to the company. Van Buren suggests a number of implications this has for managers, with the following most applicable to team leadership:
Van Buren says the social performance model forces some tough questions, like, is contract work "being used to escape obligations for fringe benefits due other, core employees?" But he also notes that besides the ethical considerations, there are tangible benefits to ethical behavior. For example, "just treatment of downsized employees can be beneficial to the firm, because surviving employees will feel more at ease and thus maintain their commitment…" There also has been research showing a link between corporate social performance and financial performance.
Application: Van Buren stresses that financial benefits are beside the point. Work organizations are nothing more than groups of people; that means the same standards for ethical behavior apply at work as apply at a religious organization, which is also just a group of people. For corporations, I have some additional logic: You and I are judged on our ethical behavior based solely on standards of right or wrong. Whether it helps us earn more money is not even a consideration. In the United States, at least, a corporation is literally treated as an individual person under the law. That being the case, we have the right to demand ethical behavior from corporations for the sake of ethics alone. It should be part of the price corporations pay for the benefits of their legal definition as persons. Either way, the workplace is not exempt from ethical standards.
If you're a manager, this means you. It means you can't just ask yourself how you're going to get everything done that your managers have put on you. It means you have to ask yourself how you're going to get it done. Will you do so with respect for your employees as human beings deserving of the same decent treatment you try to give your friends and family? Or do you really think of them just as means to your end of getting the work done?
Bear in mind this: 100,000 years ago, 10,000 years ago, throughout most of human existence, people spent their entire lives living, playing and working in small groups of extended family. In other words, our friends, family members, and co-workers were all the same people. Whey, then, would you now treat your employees any differently than the people you spend the rest of your time with?
Source: Van Buren, H. (05), "An Employee-Centered Model of Corporate Social Performance," Business Ethics Quarterly 15(4):687.
Study: When people needed to constantly interact with others to accomplish work, planning was not as important as good processes for coordination in a recent study.
Just as individuals work in a wide range of combinations—"sole contributors," pairs, groups and empowered teams—so too can teams. In many small businesses, the team is the size of the whole company. Depending on the nature of the business, it may be able to accomplish the company's entire output with no coordinated help from others. However, most teams require some cooperation with other teams, and there are teams on the other extreme that must coordinate their work constantly with that of other teams. These "multiteam systems," as the research team of management professors Michelle Marks of George Mason Univ. and John Mathieu of the Univ. of Connecticut call them, are only beginning to receive scientific attention.
Teamed up with three other researchers in a study funded by the U.S. Air Force, they set up air-combat computer games where a pair of undergraduate students in the roles of pilot and weapons specialist had to work with one other pair and six aircraft controlled by the computer. One pair was responsible for air-to-air combat, and the other for attacking antiaircraft threats on the ground. The students wore headsets to communicate and could flip a switch to talk to the other pair. Their missions were varied by the researchers so the teams could succeed 1) without coordinating, or doing so in a certain sequence of events, or 2) only if they cooperated freely and closely. (The researchers had intended the parts of #1 to be separate, but the results for the two were basically the same.)
After assignment of roles, training, and a practice session, each set of pairs was given time for planning and then "flew" three missions. The quality of the planning was rated based on interviews with each mission leader (the "pilot" of the air-to-air team). Subject-matter experts observed and listened to the pairs during each mission to rate the "action processes" within and between aircraft. Finally, to rate performance, each mission team received points based on destroying targets, preventing damage to or destruction of the human- and computer-controlled aircraft, and not hitting allies or neutral targets (final scores ranged from -55 to 280).
The quality of action processes within and between teams was strongly linked to team success (a correlation of +.58 for the "between" processes). Planning had some overall effect on between-team actions and performance, but not by changing action processes (more on this below). More to the point of the study, the type of goal changed the importance of within-team versus between-team processes. When the teams needed to cooperate to succeed, "those that were able to coordinate and monitor across…teams were more successful in achieving the collective mission." Where team cooperation was not as critical given the goal, processes within the teams were more important to success.
Against the researchers' expectations, planning only helped performance when the goals did not require cooperation. But they speculated that this was a question of the focus or quality of the planning. Teams tended to focus on within-team processes instead of how to coordinate team actions. When they did the latter, the plans were "well thought out" but "not flexible or adaptive," which certainly is not a plus in a combat situation. Finally, because they had to interact a lot during missions requiring cooperation, "teams were forced to readily develop plans on the fly…as they were performing the task," so the pre-mission planning was not as relevant.
Application: The "limitations" of this study, to use the word scientists use, don't allow me to give any advice based on it findings yet. This study was a preliminary look at a complex issue, and the "teams" in the study were, as the authors note, just pairs of people, not teams as defined in the business world.
The most interesting part of the study for me was the part researchers admit they got wrong. Their theorizing as to why the planning phase did not help in the missions in which the pairs needed to cooperate is a great reminder of the importance of asking why something did not work as expected. I regularly see evidence of people "throwing the baby out with the bath water" in business. For example, the word "teambuilding" is received with great skepticism by most group members these days, because they have been forced to go through so many ineffective teambuilding exercises. This study is not an indictment against planning, but can be viewed as a warning to consider whether the planning you are doing is focused on the right areas and is flexible enough for the environment and goals of the project. Similarly, don't just say, "oh, teambuilding doesn't work." Ask whether the teambuilding you have done in the past was scientifically valid, adapted to the specifics of your team's situation, and performed properly.
Source: Marks, M. et al. (05) , "Teamwork in Multiteam Systems," Journal of Applied Psychology 90(5):964.
Article: An article by researchers for researchers does a nice job of explaining why both lab experiments and studies in companies are needed to fully explore what makes teams tick. In the process, it also explains why you should be willing to question your own beliefs about team management if the research tells you something different.
Scientists tend to specialize in one kind of research (lab or "field" studies). Although they refer to studies from the other sphere, they rarely directly relate the two, much less perform both types to explore an idea they have. Business researchers Jennifer Chatman of the Univ. of California, Berkeley, and Francis Flynn of Columbia Univ., suggest that the only way to completely harness the power of both lab and field research is to combine them in "a full-cycle approach to conducting organizational behavior research." In doing so, Chatman and Flynn do an excellent job of pointing out the relative strengths of each type of research study. Lab experiments on teamwork collect a group of people in a controlled way and manipulate them by varying specific factors in whatever task they are assigned. Field researchers go into existing organizations to "observe or assess natural phenomena, (using) surveys, archival studies, observation and interviews." In other words, field studies look into phenomena as they exist in the workplace instead of manipulating them, providing these advantages when testing an idea:
But that complexity makes it very difficult to determine which of the many things going on actually caused the effects the scientist is interested in. Lab experiments therefore offer a different set of advantages related to the researcher's idea:
As a result, the authors recommend that their fellow researchers either learn how to do both types of research or team up with scientists that specialize in the other type. Essentially, the cycle they recommend would start with getting an idea from the real world. Then the scientist or team would do some experiments to clarify the idea. Next they would test it in the field, and then run experiments on new questions raised by the field work. This cycle would continue until all of the work indicates the idea is both accurate and important to understanding how organizations work.
Application: You may not think this article applies to you, but it should raise questions about the sources you use in creating your ideas about teamwork. I'll draw an analogy from medical studies as reported in the news. All too often a medical study will get news coverage and people will make changes to their lifestyles even though the scientists themselves say it is too soon to be sure the study was right and "generalizable" to everyone. A few years later a new study will come out that draws the opposite conclusion, and people blame the scientists for changing their minds. The truth is, the problem comes more from poor news reporting that doesn't consider details of the study and where the study is in the scientific learning cycle.
Science learns the exact same way you learn about something when you put your mind to it. For example, when you decide to really master a software program, you might read a book and the program's Help files (that is, build from what is already known, getting ideas from several sources). Next you probably play around with the program and/or go through some tutorials (experiment based on what you have learned). Then you start applying what you now know as you work in the program (study your ideas in "the field"). Usually you have to repeat some of the earlier steps until you find the best ways to use the program given your situation and needs (experiment some more, then try the new information in the field). That process of yours is the equivalent of full-cycle research.
But I have run into few managers or team members who really set out to "master" teamwork. Doing so requires the same level of commitment, but because there is more to learn and more people to learn it, mastering teamwork takes even more time. Many will read an occasional book, maybe apply a few of the concepts with more or less success, and fail to consider how much easier their lives are when they really master any skill. How much time could you save in the long run if you mastered the use of your word-processing or spreadsheet program?
That being the case, I wonder how much more you could save if you mastered the workings of your team?
Source: Chatman, J., and F. Flynn (05), "Full-Cycle Micro-Organizational Behavior Research," Organization Science 16(4):434.
TeamResearch News summarizes the latest information from studies or articles on business teams, along with guidance on how to apply that research in your workplace. It is published the first full weekend of each month as a free service from TeamTrainersTM Consulting (www.suddenteams.com). Learn how to subscribe below and see the newsletter Web page for details about the newsletter, cautions about studies, and our privacy policy.
You may reprint any part of this newsletter at no charge in any electronic or print publication for which authors do not receive pay for individual articles, subject to the conditions below. This includes but is not limited to company and nonprofit organization newsletters, Web sites, intranets, etc. If authors are sometimes paid on a per-word or per-article basis, contact me to arrange reprint rights. The conditions for free publication are:
The right to reprint does not imply the granting of any other rights, and all copyrights remain the property of Jim Morgan.
Plain-text e-mail announcements are sent at no charge to subscribers whenever a new issue is posted, containing a list of that month's studies and articles and a link to the newsletter. To:
Your questions and suggestions are always welcome. Contact:
Jim Morgan
Head Coach, TeamTrainers Consulting
(425)
770-8595
Phone Hours: 9 a.m. to 10 p.m. every day, U.S. Pacific Time
jim@suddenteams.com
www.suddenteams.com
All content in this newsletter, including the title, is Copyright 2003-5 by Jim Morgan dba TeamTrainers Consulting. All rights reserved.
"SuddenTeams" is a registered trademark (US Trademark #2,456,849) and "TeamTrainers" and "The Science of Teams" are trademarks of Jim Morgan dba TeamTrainers Consulting.
TeamTrainers Consulting makes no guarantee or warranty regarding the use of information in this newsletter by individuals not employed by or under contract to TeamTrainers Consulting and performing official TeamTrainers business.