Atul Gawande is a surgeon and author who has written some excellent books and New Yorker articles reflecting on the state of modern medicine. Recently, his writing has gone beyond medicine in interesting ways. As he looks for lessons for medicine from other disciplines, he ends up with things to teach both medical professionals and skilled knowledge workers more generally. His book The Checklist Manifesto manages to be a riveting 224 pages on what ought to be one of the least interesting topics possible: the checklist.

So I was intrigued to see a link to a New Yorker article from Dr. Gawande on my own specialty, coaching. It’s as good as I might have hoped. Noticing that his own performance as a surgeon seems to have plateaued, he wonders whether a brief experience with a tennis coach might apply to surgery:

One July day a couple of years ago, when I was at a medical meeting in Nantucket, I had an afternoon free and went looking for someone to hit with. I found a local tennis club and asked if there was anyone who wanted to play. There wasn’t. I saw that there was a ball machine, and I asked the club pro if I could use it to practice ground strokes. He told me that it was for members only. But I could pay for a lesson and hit with him.

He was in his early twenties, a recent graduate who’d played on his college team. We hit back and forth for a while. He went easy on me at first, and then started running me around. I served a few points, and the tennis coach in him came out. You know, he said, you could get more power from your serve.

I was dubious. My serve had always been the best part of my game. But I listened. He had me pay attention to my feet as I served, and I gradually recognized that my legs weren’t really underneath me when I swung my racquet up into the air. My right leg dragged a few inches behind my body, reducing my power. With a few minutes of tinkering, he’d added at least ten miles an hour to my serve. I was serving harder than I ever had in my life.

Not long afterward, I watched Rafael Nadal play a tournament match on the Tennis Channel. The camera flashed to his coach, and the obvious struck me as interesting: even Rafael Nadal has a coach. Nearly every élite tennis player in the world does. Professional athletes use coaches to make sure they are as good as they can be.

But doctors don’t. I’d paid to have a kid just out of college look at my serve. So why did I find it inconceivable to pay someone to come into my operating room and coach me on my surgical technique?

The rest of the article wanders through a history of coaching; interesting examples from sports, music, and education; and describes his own experience engaging a coach. He concludes,

There was a moment in sports when employing a coach was unimaginable—and then came a time when not doing so was unimaginable. We care about results in sports, and if we care half as much about results in schools and in hospitals we may reach the same conclusion.

I value coaching enough to spend my own money on it. I’ve hired a mountain bike coach, Lee McCormack, to help me prepare for this summer’s Trestle All Mountain Enduro race. It’ll be my first downhill race. I don’t expect to win, but I want to get a result I can be happy about and enjoy the experience.

I used to do cross-country mountain bike races, and I have a pretty good idea how to train for an event. I have Lee’s books. I could probably do this on my own. But I know from my own experience as a software development coach how much faster a good coach can help you improve.

Lee McCormack on his backyard pump track

After just two hours of coaching—working on things I would have said I already knew how to do—I could see a marked improvement in my skills. And I had a nice list of things to practice on my own.

This brings me back around to software development. Our world today runs on software. But most software teams struggle to deliver anywhere near as quickly and reliably as they could. A software profession living up to its potential would transform the world. So, to paraphrase Gawande: If we care half as much about results in software development as we do in sports, how is it imaginable that so few teams engage a coach? How is it imaginable that so many teams with access to coaching fail to make the most of it?

What about your team? Do you have a coach? If so, do you make the most of the coaching you have available to you?

Related posts:

1. Refactoring Things Other Than Software
2. How to Invest Less and Make More From Your Software Projects
3. UI Sketches for Distributed Teams

Esther Derby has a good post this morning about how trust is embedded in a context. She writes, “The sort of trust that you need for a productive working relationship is different from the trust you need for a healthy marriage.” She gives some good examples of what trust means on a work team.

I believe trust always comes down to this: I believe that you’re not going to do me harm. What kind of harm depends on the context in which we have a relationship. On a work team with me, you can harm me by not doing your work or by complaining about me behind my back, as Esther describes.

My belief that you’re not going to do me harm comes from the accumulation of everything I know and have experienced of you. Everything that happens in our relationship either builds or undermines trust. Nothing is neutral.

Because of that, one of the best ways to build trust in a relationship is to simply be aware of it. A good tool I’ve found for that is cultural anthropologist Marvin Mayers’s prior question of trust (or PQT for short): “Is what I’m doing, thinking, or saying building trust or undermining trust?” Of course, you can never be sure what effect a given action will have on trust—people aren’t that predictable. But asking the PQT in your head before acting can point you in the right direction.

No related posts.

A recent essay in Wired says, “The traditional office, meanwhile, remains a black hole of interruptions, procrastination, and soul-crushing politics. According to Gloria Mark, an informatics professor at UC Irvine, the typical office worker is interrupted or switches tasks every three minutes—hardly enough time to accomplish anything of substance.” (via Kathy Sierra) The alternative, according to the article, is telecommuting. For everyone.

I love working from home. Given a choice, I’d rather not commute, and I’d rather have meals and breaks with my family. And when I’m doing solo projects, I’m definitely more productive there than in an office. For team projects, especially software development, however, I’ve never seen a dispersed team become anywhere near as productive as a high-performing collocated team.

The solution to the problems of the traditional office may, for some workers, be to do away with the office entirely, as Wired suggests. But that may be throwing the baby out with the bath water for the large number of workers who do team work. Telecommuting solves some problems and introduces others (e.g. isolation, communication overhead, potential for task orientation over results orientation). A better solution: fix the office environment instead of abandoning it.

A few modest proposals…

1. Eliminate multitasking. Assign workers to a single project and allow them to see it through to completion. Within a project, allow them to complete one task at a time. For interrupt-driven roles like technical support and maintenance, allow workers to do just that role and to see individual cases through to completion. (Kanban systems are perfect for managing work this way.)
2. Collocate teams. Once teams are working on a single project, put them together in the same room. Conversations will be more focused on the project goal and will be less distracting. Increased collaboration and face-to-face communication will lead to more productivity and improved morale. People enjoy accomplishing things with other people; make it easy and natural to do just that.
3. Measure up. Too often, metrics reward the wrong things and lead to unintended consequences because they measure details of the work rather than results. For software development, find ways to measure the delivery of business value by the team. Leave the implementation details for the team to manage on their own. For other disciplines, the Results Only Work Environment started at Best Buy looks like a good framework for finding the right results-level metrics and letting go of details like hours in the office.
4. Allow telecommuting. Once you start using the right metrics, workers may find that they can be more productive out of the office. Not all work is well suited to the office environment. Let them go.

Related posts:

1. Tech work is messed up…and we can fix it

Kathy Sierra tweeted: “The big Q: how much does the *perception* of working in tech need to change, and how much does the *reality* need to change?”

I’m focusing my career on the belief that tech work is *really* messed up and that it doesn’t have to be. If a team I coach gets more productive but doesn’t get happier, I haven’t done my job. The big win with agile/lean/TOC is that they align work with how humans actually function: limited attention span, need for community, continuous learning and limited ability to predict the future, need for frequent positive reinforncement.

No related posts.