My first two posts in this teamwork rumination (last week’s post here and yesterdays “part 2” here) set up the idea that “great teamwork” really comes from proactive, high-quality contributions of individual team members. In this post I want to relay a few thoughts about what team member attitudes are behind such contributions, and additional examples of what it “looks like” on projects. I personally think that to have any chance of achieving the teamwork we want, we have to be able to concretely describe what it looks like. Conceptual alone doesn’t cut it, how does everyone need to behave, what kinds of thing should they DO? (NOTE: later this week I’m going to cover the project manager as part of the ‘teamwork equation’ and how project managers choose to play their role can either foster or destroy great teamwork. Hope you’ll keep reading this week for that!) When I think about the people I value having on my project teams, I think about the people who know how to make a difference no matter what the circumstances. Those people demonstrate “ownership” of project outcomes, and “initiative” to contribute in different ways to make those outcomes a reality. What’s the difference between those people, and those who I tend to peg more as “whiners,” people who perhaps give up in the face of adversity or complexity; perhaps don’t see it as “their role” to take the lead in pushing past challenges?
I see the difference expressed this way: it’s a difference in attitude that then drives very different behaviors. It’s the difference between “vanquishers” and “victims.” In the face of tight deadlines, changing project requirements, resource conflicts: . vanquishers understand the role they can play, the influence they can have. They speak up, identify problems, suggest solutions, take a stand on tough issues, make things happen: and participate from the beginning to help the team avoid problems in the first place. (That’s great teamwork.)
Yesterday’s story about Steve illustrated how such team members contribute to the front end of a project. He demonstrated initiative to push for the right business decisions and thereby helped the team interact around severe requirements issues and time constraints to ultimately work together and make sound team decisions on project scope. Steve was definitely a vanquisher. So what do such team member and team-building contributions look like during the design, implementation, and test phases of our projects? What does it mean to be a vanquisher then?
With technical teams, the design and implementation phase is usually team members’ favorite part of the project. Even when significant technical challenges are present, we can put up with it: we’re having a great deal of fun being creative, solving complex problems, bringing a design to life. So it doesn’t seem hard to be a positive, enthusiastic, contributing team member. However, hidden pitfalls abound that will trip up “victims” every time, but give vanquishers an opportunity to shine. Significant requirements changes in the middle of the project that force them to throw out completed work. Or serious design flaws rearing their heads when developers are almost done with schematics or layout or code. Or test phases executed in a pressure-cooker atmosphere because of inadequate time left for thorough testing and/or an overwhelming number of “bugs.”
So how does a vanquisher team member contribute to a great team in those situations? Consider these scenarios:
An influential engineer or an executive walks into the developer’s office and requests a feature change that will perturb the schedule and violate the specs the cross-functional team agreed to earlier in the project. The victim-to-be takes every request like this and executes it without question (while probably grousing about the exec being out of control). The later result for him could be overtime to make the change or anguish when the quickly-made modification causes an integration problem with other components. The near-term impact could be disillusionment with the company’s requirements process, anger at the executive, and even loss of buy-in to the project’s deadline. The vanquisher, on the other hand, understands the importance of the current project plan and how critical it is to not make such changes capriciously. He or she knows that the change could have all kind of implications, especially if it’s done quickly. Fast changes often result in sloppy design patches, later integration issues, additional bugs to fix, or unacceptably reduced test time at the end of the project (since the extra time for design changes has to come from somewhere!) The vanquisher would instead acknowledge the person’s issue, then raise it to the project manager along with all the potential implications. The impact on the entire project would be addressed, with the vanquisher contributing ideas and alternatives before such a change was taken on – if it ends up being taken on at all. The vanquisher has likely saved himself and other team members significant time and trouble by having the courage to “push back” and help make sure the right decision is made by the team. The vanquisher similarly tends to act as a warning-raiser, idea-generator, objective alternative-analyzer, and decision-catalyst, in any of the typical problem scenarios I raised above.
What about teamwork to avoid such problems in the first place? Think back to the most painful project end-games, including testing, that your team has ever experienced. Ill-planned integration efforts where it seemed the pieces would never start working together. Slow, inefficient system test efforts due to the test group getting hardware and software that weren’t really finished. Never-ending test phases where each fix seemed to produce new bugs. Products shipping to a customer, only to crash on the first day of operation, because the test plan wasn’t thorough and real world. Your development team members are obviously not the project manager, functional manager, or test manager – the people typically seen to have overall responsibility for planning and managing these efforts. But those developers still have a great deal to contribute to help make sure these nightmares don’t occur. The developers are closest to the design details. They’ve had to implement those requirements. If your developer team members are acting as vanquishers, they’ll speak up during planning about what types of testing should occur and how they should be organized. They’ll make sure they do thorough design reviews to eradicate bugs early, where they cost less and are far less painful to deal with. They’ll help make sure that they and others tightly control late changes and bug fixes, make only the necessary ones, and review the changes appropriately. In short, those team members’ oversight of these issues is at least as valuable as that of all the “managers” involved.
This to me is effective teamwork. Yes, it reaps warm and fuzzy type ‘team feelings’ in that you’re much more likely to have a happier team through the project if sticky problems are dealt with smoothly. But that’s just the result, the reward: the true teamWORK was what the individuals did in collaboration with each other, to keep the team functioning, the project on track, the issues resolved or avoided in the first place.
So think about your project’s design, implementation, and test challenges. Where can you and your technical team members take more ownership, take more initiative, and act as valuable “vanquishers”? If you’re a project manager working to influence more of this behavior on your team, here’s a big side benefit that can help you sell it: The fact is, Vanquishers are highly-valued. They get listened to, appreciated for their maturity, promoted, and given the best opportunities on the next project. Those rewards, and the advantages of such great teamwork, can and should go to you and the other members of your team.
