If two projects in your organization require specific expertise that only one employee has, what do you do? Projects need to stay on track, but one person certainly can't be everywhere—or even two places—at once. In this column, Johanna Rothman shares a story of an organization stuck in the specialist mindset and offers some tips on how to escape if you're stuck there, too.

Esther Derby has been thinking about trust in the workplace a lot lately, and the absence of trust, too. When she asks people what it's like to work in a group where people trust their managers, they tell her information flows freely, conflict is productive, and that they can tell their managers what they think without fear of retribution. On the other hand, when trust is absent, people hide information, look out for themselves, don't bring up new ideas, and withhold effort.

Back in the day of cross-Atlantic boat travel, luggage that wasn't needed during the long journey was labeled "Not Wanted on the Voyage" and stowed away below decks. In this column, Fiona Charles suggests that testers can also be viewed as heavy baggage and not exactly welcome by some parties during the journey of software development. To understand why others might think this way, Fiona takes a good, hard look at what testers do that could possibly make them undesirable team mates.

If you're working on more than one project at a time or if your managers are asking you to do so, it's time to make some decisions. Not every project should be started or finished, and certainly no one person or team should work on all projects at the same time. The organization needs to make some decisions about whether to commit to a project, kill it so it doesn't interfere with other projects, or transform it so it can succeed in a reasonable time.