One of the biggest lessons I have learned professionally is that software development is a team sport. I can mentally picture a few people hitting their caps lock key and getting ready to tweeter at me. Maybe the better phrase is “the business of software development is a team sport.”
I did not play many team sports as a kid and I was not a big fan of watching most sports on television. I think I developed an appreciation for the intricacy of team sports when I started to volunteer my time as a coach and as a referee for youth sports for my oldest son—I learned a considerable number of valuable lessons from that experience.
I spend a lot of time regurgitating the phrase “shared understanding” at work. I think that you get much better software outcomes if everyone has shared understanding. I appreciate it when I work with people who ask good questions when they do not have shared understanding. I also appreciate it when people write their product definitions for development teams in a way that fosters easy shared understanding.
I have talked about shared understanding in the past and will probably talk about it again in the future. Today I want to talk about something else. I want to talk about baton passing.
The term comes to us from relay races. I think a lot of activities in software development resemble relay races and include moments where people must pass the baton from one person to another.
Sometimes people are not aware that they are in a relay race. It is really hard to win a relay race if you do not know you are waiting for a baton, or if you do not know you should be passing a baton. In software development terms I have seen people finish a task that someone else is waiting on without any communication that the task is complete. I refer to this moment as “dropping the baton”.
You might see this pattern at work yourself. It is a dangerous pattern because it creates inefficiency and delays. Even worse, it can create emotional baggage as people try to pin blame on folks for the baton-drop.
It is not important to blame someone for dropping the baton when it happens.
Whenever I spot a dropped baton, I try to do two things.
The first thing is to make sure that the baton gets picked back up. You should get back in the race as fast as possible.
The second thing to do is to figure out how to prevent the baton from getting dropped again.
This is harder than it sounds. It takes time to build good communication habits. I generally tell my relay race story to people once or twice a year in any given organization, especially after witnessing one or two baton-drops.
I have seen a significant number of baton-drops in the past few weeks and thought it would be good to write about it.
I may have even dropped one of those batons myself.
It is important to make sure you know what relay races you are running as a part of your job. It is good to communicate your expectations around baton passes to people in front of you and to people behind you. The more explicitly this gets communicated, the more successful the relay race will be.
I do not have much more to say on the subject.
I need to go pick up some batons and make sure that they do not get dropped again in the future.
Thank you for reading my short anecdote today. I apologize for not having a funny closing statement. Instead I can offer you a chance to slide some sweet, sweet nickels into my pocket by putting a referral code in a hilarious business poster you can put on the wall to gaslight your coworkers (Per Amazon’s Affiliate Policy, I must disclose that I get crazy-mad profits if you Buy This Sweet Merch).
