An Unplanned Experiment

[article]

Relieving the three of all other responsibilities was also crucial. For the duration of the project, they didn't have to contribute to the department's status reports. They didn't have to attend meetings. They didn't have to face all the work-related and did-you-hear-the-one-about interruptions that were routine. They were spared all the politics, the repetitions of "just one more change," and the persistent problems and pressures that characterized so many of our other projects. They had a job to do, and that was their singular responsibility.

Sending them offsite was also critical to their success. Remaining in their cubicles with endless distractions would have been a recipe for failure. But even relocating them elsewhere in the same building would have backfired since they'd have been interrupted repeatedly with "I just need a minute of your time." Having them out of sight, if not out of mind, was significant, especially since none of us worker bees knew where they were. Otherwise, despite management's warnings to stay away, we would have been tempted to drop by just to see how they were doing.

Although this strategy wasn't intended as a grand experiment, it served as such. It was as if management had asked, "How might productivity be affected if we carried out a high-priority project under optimal conditions?"

I would have loved for the company to have treated the situation as a genuine experiment, creating a control group that tackled the exact same project under everyday conditions. Comparing results of the two groups at the end of the mandated time period would have been fascinating. Instead we used our ample experience with other development projects as an ad hoc control group; based on that experience, completion in twelve weeks was unthinkable.

Sending a high-performance team offsite to do the impossible may not be a strategy that IT organizations can use on a regular basis. And it's possible that even this team would have faltered with a longer project or a follow-on project under similar circumstances. But it proved to me—and to many others in the company—that sometimes the best productivity improvements are not the result of tools, technologies, or methodologies, but just leaving people alone and letting them do their job.

Tags: 

About the author

Naomi Karten's picture Naomi Karten

Naomi Karten is a highly experienced speaker and seminar leader who draws from her psychology and IT backgrounds to help organizations improve customer satisfaction, manage change, and strengthen teamwork. She has delivered seminars and keynotes to more than 100,000 people internationally. Naomi's newest books are Presentation Skills for Technical Professionals and Changing How You Manage and Communicate Change. Her other books and ebooks include Managing Expectations, Communication Gaps and How to Close Them, and How to Survive, Excel and Advance as an Introvert. Readers have described her newsletter, Perceptions & Realities, as lively, informative, and a breath of fresh air. She is a regular columnist for StickyMinds.com. When not working, Naomi's passion is skiing deep powder. Contact her at naomi@nkarten.com or via her Web site, www.nkarten.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!