Showing posts with label teams. Show all posts
Showing posts with label teams. Show all posts

Teamwork – What Does Work

>> Wednesday, August 5, 2009

funny pictures of cats with captions
see more Lolcats and funny pictures

Yesterday, I wrote up some things I’d observed over a couple of decades with regards to teamwork and what doesn’t work. You may not believe it, but I’ve also seen some very effective teams (they get less press) and I thought I’d add a list of things I’ve observed do seem to work. Bear in mind, (a) this is my opinion based on my observations, and (b) no guarantees this always works.

What things work to make a successful team?

A single definitive leader/decider. Consensus is a great goal, but attaining it is often challenging (if not impossible). The buck has to stop with someone and a good leader can make it happen, hear all the back and forth and take a stand. Taking a stand/making an actual decision is the key to efficiency of a team, but it also means that the answers coming out are less likely to be mushy or ambiguous. Which means a leader needs to be able to stand up to the rest of the team – if it’s called for. A good leader can dole out assignments effectively, streamline communication and prod the slower folks to make sure things happen on time. A good leader can also help keep meetings from digressing into nonsense or traipsing off onto inconsequent tangents. There are, of course, some things a leader should not do, like micromanage teammates or ignore the inputs of his teammates.

Have a plan. Know your goals, your requirements, your deliverables and your schedule. Put ‘em in writing and get the ones tasking your team to buy into them. Anything that’s fuzzy on this list is going to be time wasted doing the wrong things, following the wrong path, getting corrected. Know what you’re there to do and choose a path to get there as early in the flow as you can. Sometimes things just fall into place. Usually, however, they don’t.

The right people. An effective team has the right players: experts, integrators, users, operators, safety, all the players necessary to ensure each step of the development is addressed, and, preferably, at least a couple of folks with a big picture perspective to make sure it all works together. Each person should be able to contribute something or they are dead wood. And, if you have to go outside the team repeatedly for this or that data or expertise, your team isn’t complete.

Egos in check. This applies to everyone. If someone is incapable of checking her ego at the door, she is going to be a relatively useless, if not counterproductive, member of the team. Each teammate should be a contributor and all must be willing to challenge conclusions or inputs in order to weed out the weak or ill-supported ideas. And that means being able to take that challenging without getting steamed. Leaders must also take care. It’s important to have the self-confidence to stand up for the group’s work, but it’s a poor leader who thinks no one can do anything worthwhile but himself.

Ability to work independently. If you’re idea of teamwork means all the work is done in meetings, you aren’t much help. Meetings are, in my experience, some of the least productive hours in anyone’s day. The time between meetings is the time to put stories together, gather data, analyze information, reach conclusions. Then, you’re making the most of that meeting time by using it effectively to polish and question those stories instead of trying to right them by committee. And being able to work independently shouldn’t mean trotting to the leader every fifteen minutes for clarification. Get your assignment, understand it, then do it.

Know your history. It’s too easy to make assumptions right off in a new project about what to do and what is best. Take a few minutes and look at what’s been done before, mistakes made, missteps, what’s worked. No sense making a mistake others have already made. Go on, be original. Make your own mistakes. Often the starting point to a difficult project can fall right out when you look at the past. And assumptions you thought were a done deal, um, weren’t. You may even know why.

Honesty. A team that decides the conclusion before starting is inherently dishonest. A team that finds something startling (even dismaying) and doesn’t come clean is also dishonest. A dishonest team’s findings and work are useless. They don’t mean anything if not built on an honest foundation. Not only will your product be flawed, but the entire team will be tainted by the dishonesty. People forgive mistakes – we all make them – but dishonesty can follow you the rest of your life.

A documentation trail. Sounds stupid, but it’s pretty important. Put actions, assignments, decisions on paper, and add why. Keep drafts of documents so you know where you’ve been. This is less important on a short term project, but, for something that might last months, it can be the key to not doing tasks because you forgot why you did them, forgot what results you obtained, forgot why you didn’t do them, or even forgot you did them. When the story comes together, you better know how you got where you got and a documentation trail can be difference between success and failure. Rationales, conclusions, data and sources, all should be documented as you find them and then they’re never lost. (Note, there’s often someone tasked to keep up with all this – this job can be as important as the leader and it’s often a key position when it comes to putting it all together, too. Be nice to this person.)

Communication/writing skills. Here’s the sad part. No matter how good your research, your data, your conclusions, your logic, your design, your plan, if you can’t sell it effectively, it doesn’t mean anything. That means being able to express it in terms that any potential audience can understand without insulting their intelligences (which is harder than it sounds). That means knowing how to present it so that it has the most impact, instills the least boredom, sounds the most convincing. If there’s no one on the team capable of pulling this together effectively, the caliber of the team is almost moot.

Read more...

Teamwork - What Doesn't Work

>> Tuesday, August 4, 2009



I talked about collaboration yesterday, specifically the odd one my husband and I have regarding writing (which is different than the strange collaborations we have for everything else).

Teamwork is somewhat related to the topic of partnerships, only the dynamics tend to be much more complex. Now, I'm not going to tell you the right teams or what is always good or always bad. However, I can tell you some of my experiences and what I think helps (and doesn't help) make a good team. For those of you who do a lot of interactive and team work, I expect I won't be telling you anything new.

One thing about working for the government, I have seen a lot of the features that DON'T make for a good team - though they are not restricted to government and contractor organizations (and, yes, I have seen teams that work here, too):

Too many chiefs, not enough Indians. There are many organizations out there where the management structure dwarfs the working segment. It's a recipe for waste, inertia, and making poor decisions.
  • In such an environment, decisions are often amorphous and preliminary much longer than they should be because it's under constant review - middle management has nothing else to do so they do meetings, reviews, reevaluations.
  • Poor decisions stay in place far longer than they should because no one can reach concensus on the alternatives or, because those "making the decisions" don't really understand it so they're afraid to change it.
  • Decisions are made more on the slickness of the presentation rather than because it makes sense because someone who isn't knowledgable is most influenced by good advertising.
  • Meanwhile, while the management isn't accomplishing even what they are supposed to be providing (meaningful direction), they are sucking away resources (salaries), leaving the small cadre of real workers not only overworked, but often performing more work than necessary because they have to keep redoing things to try to get a reasonable product. That, of course, also reduces feedback so that management doesn't find out what's wrong until far too late.
No chiefs at all. While one can make an argument that there are teams that can be successful using pure consensus, but my experience says that this is almost always (a) a very small team, (b) a loosely integrated final product, and (c) usually has someone tacitly if not overtly leading it. However, I feel that, under most circumstances, leaderlessness leads to inefficiency. Independent work tends to be limited. Nothing can be accomplished except in the meeting because consensus is always required. (And we all know how productive meetings are without leadership). But, more than that, it's often hard to get a group to reach a definitive answer, use their time effectively. Or, equally challenging, the need for total agreement can dissuade dissension as people don't want to be the one holding everyone back - and decisions get made on what people think everyone else wants to do rather than what they ought to do.

Not enough experts. Too many folks with not enough actual expertise makes a meeting an exercise in action items with everyone going to "find out." If people don't have the understanding and knowledge to resolve the situation when decisions are to be made, decisions won't be made. If a team requires expertise outside (and doesn't have it IN the team), the team is poorly designed.

Too many experts. Expertise is great and definitely something to include in a team, but if everyone's an expert (particularly if you have experts in the same field), there is a definite risk of egos getting in the way of solutions. Experts can compete (and torpedo each other), can get distracted by by inconsequential trivialities instead of addressing the whole problem. Experts are important, but an effective team usually needs people to (a) provide a fresh perspective and (b) to put the story all together find the "answer".

Not enough (or ineffective) communication. Teams cannot work effectively in isolation. Anything that blocks communication, blocks progress, leads to misunderstandings, tasks or considerations falling through the cracks, doing work more than once, or pieces that work fine independently but not together. And that anything can be distance, poor communication skills, unnecessary bureaucracy, language, unit systems, personality, technology, whatever.

Too much communication. If everyone's statusing, meeting, discussing, brainstorming, caucusing, reviewing, reporting, etc., no one's doing anything. If it takes longer to explain what you did than to do it (to everyone you need to explain it to), you're not exactly working efficiently.

Tomorrow, the kind of things I think make a team effective...

Read more...

Labels

Blog Makeover by LadyJava Creations